JP2016024668A - User interface evaluation apparatus and user interface evaluation method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To check a display state on an external display when software is output in the external display.SOLUTION: A user interface evaluation apparatus is configured to check whether software to be output in a first display, which is a built-in display, and a second display, which is an external display, and to be run on a first computer, has a screen interface based on a rule. The user interface evaluation apparatus includes: resolution acquisition means for acquiring an actual size and resolution of the second display; design information acquisition means for acquiring information on a component arranged on a user interface screen of the software; and detection means for detecting a component where a condition on appearance on the second display does not satisfy a predetermined condition when the software is executed on the first computer and the user interface screen is output in the second display.SELECTED DRAWING: Figure 1

Description

  The present invention relates to an apparatus for evaluating a software user interface.

  In recent years, with the spread of mobile terminals such as smartphones, development environments that operate on a cross platform, that is, a platform different from a target device, have become widespread (see Non-Patent Document 1).

Since the screen of the mobile terminal is a limited size, if the developer freely designs the screen, there is a possibility that the usability is lowered. In view of this, a method has been adopted in which a rule regarding screen design is set and coding is performed according to the rule.
For example, in the system described in Patent Document 1, the code of the software to be developed is automatically checked in the development environment, and a warning can be given when a code that violates the rules is found. The rules are created, for example, by software publishers or industry associations.

Japanese Patent Laid-Open No. 08-101771

"Android SDK", [online], [Search July 1, 2014], Internet <URL: http://developer.android.com/sdk/> “MirrorLink”, [online], [searched July 1, 2014], Internet <URL: http://www.mirrorlink.com/>

  Recently, a standard for connecting a mobile computer such as a smartphone to an in-vehicle device has been proposed aiming at fusion of a portable terminal and an in-vehicle device (Non-Patent Document 2). By connecting a smartphone according to such a standard, a smartphone screen can be output on the display of an in-vehicle device (for example, a navigation device).

  On the other hand, since the display of the in-vehicle device may be viewed while driving, the GUI output to the display may be designed so as not to hinder driving (ie, not reduce concentration). preferable. Such a design is defined, for example, in “Image Display Device Guidelines” of the Japan Automobile Manufacturers Association.

When creating software that runs on a mobile device and is expected to output a screen to the display of an in-vehicle device, a coding rule that follows these guidelines is provided, and the screen It is preferable to design.
For example, coding conventions such as “character font height is greater than or equal to mm” and “button spacing is greater than or equal to mm” can be used.

The problem here is that the display size of the in-vehicle device varies depending on the manufacturer, and the screen size when it is actually displayed under the user is not known at the time of development.
In the development environment described in Non-Patent Document 1, it is possible to specify the resolution of a target device and actually emulate on the screen what kind of display is to be performed. However, when a display is connected to the outside of the target device, such as a display of an in-vehicle device, the size of the output screen depends on the resolution and size of the display. That is, it is not known until the actual machine is connected how large the components included in the screen are displayed.
Further, in the system described in Patent Document 1, it is possible to check whether a component included in the screen satisfies the convention. However, when the screen is output to an external display, what the component actually does is It cannot be checked until it is displayed in the correct size.

  In this way, in the previous development environment, it is not possible to emulate an environment in which a display is connected to the outside of the target device, so there is a rule regarding the final display size on the display However, there is a problem that it is not possible to check whether or not the coding according to the convention is performed.

  The present invention has been made in consideration of the above problems, and an object of the present invention is to provide a user interface evaluation apparatus capable of checking a display state on an external display when target software is output to the external display. To do.

In order to solve the above problems, a user interface evaluation apparatus according to the present invention provides:
Check whether the software running on the first computer that can output the screen to the first display, which is the built-in display, and the second display, which is an externally connected display, has a screen interface that conforms to the regulations. A user interface evaluation device, a resolution acquisition unit for acquiring the actual size and resolution of the second display, a design information acquisition unit for acquiring information about components arranged on a user interface screen of the software, When the software is executed on the first computer and the user interface screen is output to the second display, a component whose appearance condition on the second display does not satisfy a predetermined condition is Arco And having a detecting means for detecting.

The first display is a display included in the target device, and the second display is an external display connected to the outside of the target device.
The resolution acquisition means is means for acquiring the actual size and resolution of the second display. The actual size and resolution of the second display may be obtained by user input, for example. Further, information regarding a plurality of second displays may be stored, and a matching item may be acquired each time.

  The design information acquisition means is means for acquiring information related to the arrangement state of the components arranged on the user interface screen of the target software. A component is a component that constitutes a screen, such as a label, a list box, or a button. Any object may be used as long as the object is arranged on the screen. The arrangement state is, for example, the arrangement position (coordinates) of each component on the screen, the vertical size, the horizontal size, and the like. The arrangement position and size of each component are expressed in units that do not depend on the actual display size (physical size) such as pixels and points.

  In addition, the detection unit is a component whose condition regarding the appearance when output to the second display does not satisfy a predetermined condition based on the information acquired by the resolution acquisition unit and the information acquired by the design information acquisition unit. Detect that there is.

  According to this configuration, it is possible to check the display state of the component on the second display when the user interface screen is output to the second display. That is, it is possible to detect that there is a component that violates the rules regarding appearance in the development environment without operating the software on an actual machine.

  Further, the condition relating to the appearance may be a condition relating to an actual size when the target component is displayed on the second display.

  The actual size is the physical size when actually displayed on the second display. Thereby, for example, it can be confirmed that the size (vertical size, horizontal size) of the component that the user actually sees and the interval between the components satisfy the predetermined condition.

  The predetermined condition may be any one of a size of a character included in the component, a height of the component, a width of the component, and an interval between adjacent components. .

  By confirming that these conditions satisfy the regulations, usability can be ensured when the user interface screen is output to the second display.

  Further, the user interface evaluation device according to the present invention generates an emulation screen which is a screen emulating a result when the third display and the user interface screen are output to the second display, Emulating means for outputting to a third display may be further included.

The third display is a display included in the user interface evaluation device.
The emulation means can emulate what kind of display is performed on the second display based on the information acquired by the resolution acquisition means and the information acquired by the arrangement acquisition means.

  The resolution acquisition means further acquires the actual size and resolution of the third display, and the emulation means generates the emulation screen with the same actual size as the second display. It is good.

  Furthermore, by acquiring the actual size and resolution of the third display, the screen size at the time of emulation can be matched with the actual screen size displayed on the second display.

  Further, the user interface evaluation apparatus according to the present invention is a warning unit that warns a user when the detection unit detects that the component that does not satisfy the predetermined condition is included in the user interface screen. May be further included.

  The warning may be performed, for example, by displaying an alert on the screen, or may be performed by outputting a log. Moreover, it is preferable that the warning includes information on how the generated code deviates from a predetermined condition.

  The first computer may be a mobile terminal, and the second display may be a display included in the in-vehicle device.

  When a mobile terminal is connected to an in-vehicle device and screen display is performed using a display included in the in-vehicle device, the restrictions on the screen interface are particularly large. The user interface evaluation apparatus according to the present invention can be suitably applied to such an environment.

  The present invention can also be specified as a user interface evaluation device including at least a part of the above processing. It can also be specified as a software check method executed by the user interface evaluation apparatus. The above processes and means can be freely combined and implemented as long as no technical contradiction occurs.

  According to the present invention, it is possible to provide a user interface evaluation device capable of checking a display state on an external display when target software is output to the external display.

It is a lineblock diagram of the software creation device concerning a first embodiment. It is the example of arrangement | positioning of the component in 1st embodiment. It is a screen display example of software in the first embodiment. It is a figure explaining the information about a target display. It is an example of GUI design data and display data. It is a flowchart figure of the check process in 1st embodiment. It is an example of the display data in 2nd embodiment. It is an example of the emulator screen in 2nd embodiment. It is an example of a display of a screen concerning a modification.

(First embodiment)
<System configuration>
The software creation apparatus according to the first embodiment will be described with reference to FIG. 1 which is a system configuration diagram. The software creation device 100 according to the first embodiment is a device for creating software that operates on the mobile terminal 200.
The software creation device 100 is a computer having a processor, a main storage device, and an auxiliary storage device, and a program stored in the auxiliary storage device is loaded into the main storage device and executed by the processor, whereby each means to be described later is Functions (a processor, a main storage device, and an auxiliary storage device are not shown).

  The mobile terminal 200 that is a target device is a portable computer (a mobile phone, a smartphone, a PDA, a handheld computer, or the like), and is a terminal that executes software created by the software creation device 100. The mobile terminal 200 has a function of connecting to the in-vehicle terminal 300, and can output a user interface screen of the software being executed.

The in-vehicle terminal 300 is an in-vehicle computer mounted on a vehicle. The in-vehicle terminal 300 has a display 310 and can output a user interface screen of software being executed on the mobile terminal 200 to the display.
Thereby, a user who is in the vehicle can use application software (for example, a navigation application, a music application, a browser, an SNS client, etc.) used in the mobile terminal 200 through the large screen.

Next, the software creation apparatus 100 will be described in detail. Software creation device 1
00 includes an input / output unit 101, a design unit 102, a storage unit 103, a resolution acquisition unit 104, a rule check unit 105, and a code generation unit 106.

  The input / output unit 101 is a unit that receives an input operation performed by the user and presents information to the user. Specifically, it comprises a liquid crystal display, a keyboard, a mouse and the like and its control means.

  The design unit 102 is a means for designing software. Specifically, a screen for designing software (for example, a code editor or a screen editor) is presented to the software developer through the input / output unit 101, and software design data input by the developer is acquired. The software design data is design data on the user interface screen (hereinafter referred to as GUI design data) and design data related to logic.

Here, the GUI design data will be described. The GUI design data is data representing the arrangement of parts (hereinafter referred to as components) arranged on a user interface screen (hereinafter referred to as form) included in the software to be developed. FIG. 2 shows an example of component arrangement. In this example, a plurality of labels (character areas), buttons, images, and the like are arranged on the form 201, respectively. The arrangement of components is represented by, for example, the coordinates of the upper left point, the width, the height, the font size (in the case of a character component), and the like. In this example, labels, buttons, and images are exemplified as components. However, any components may be used as long as they are arranged on the screen. For example, it may be a list box, a select box, a check box, or the like.
A software developer arranges components on a form through an editor screen generated by the design unit 102. Similarly, logic coding is performed through an editor screen generated by the design unit 102.

When the software is executed, the components arranged in this way operate according to the designed logic. For example, as shown in FIG. 3, actual data is embedded and provided to the user (FIG. 3 shows an example of a music player).
The design data acquired by the design unit 102 is temporarily stored in the storage unit 103 by, for example, a text file in which a code is described or an XML file representing a screen design.

  The storage unit 103 is means for temporarily storing data related to software design. The storage unit 103 is preferably a storage medium that can read and write at high speed and has a large capacity. For example, a flash memory can be suitably used.

The resolution acquisition unit 104 is a means for acquiring information about a display on which a software user interface screen is displayed. The target displays are two types, a display that the portable terminal 200 has and a display 310 that the in-vehicle terminal 300 has. Specifically, as illustrated in FIG. 4, the vertical and horizontal physical sizes and the vertical and horizontal pixel numbers of the effective display area of the target display are acquired. Hereinafter, the two pieces of information are referred to as display data. A detailed example of display data will be described later.
The display data may be acquired each time through the input / output unit 101, or may be acquired each time from a plurality of preset values. Further, a plurality of target displays may be provided. Display data acquired by the resolution acquisition unit 104 is temporarily stored in the storage unit 103.

The rule check unit 105 is a unit that checks whether there is a component that deviates from the coding rule based on the GUI design data acquired by the design unit 102 and the display data acquired by the resolution acquisition unit 104. The contents of the coding rules and a specific checking method will be described later.

  The code generation unit 106 is a unit that generates (builds) an executable program based on the code acquired by the design unit 102. The built program is finally output as a software package in a distribution format. Note that the code generation unit 106 may have a function of transferring the software package to the mobile terminal 200 by wired connection or wireless connection.

<Check method>
Next, the coding convention will be described. The coding convention in the present embodiment is a set of restrictions on the size or position of components included in the form when the form is displayed on the display 310. The coding convention in the present embodiment includes, for example, at least one of the following. The “size”, “height”, and “interval” shown below are all actual sizes (mm) on the display 310.
(1) The height of the character string associated with the label is greater than or equal to a predetermined value (2) The number of characters in the character string associated with the label is less than or equal to the predetermined value (3) The interval between components is greater than or equal to the predetermined value (4) The vertical and horizontal sizes of the buttons must be greater than or equal to the specified values. The coding convention to be used is related to the appearance of the components included in the form when the form is displayed on an external display. If it exists, it may be other than those exemplified.

  The GUI design data acquired by the design unit 102 is obtained by designating the arrangement of components by pixels. FIG. 5A is an example of GUI design data acquired by the design unit 102 and stored in the storage unit 103. Here, coordinates on the form (upper left coordinates of the component), width, and height are defined for each component.

On the other hand, it is impossible to estimate what size each component is actually displayed on the display 310 using only the GUI design data. Therefore, the software creation apparatus according to the present embodiment performs emulation when the form is displayed on the display 310 using the display data. Specifically, the GUI design data represented by the number of pixels is converted into an actual size (physical size) on the display.
For example, consider a case where the actual width of the display 310 is 250 [mm], the horizontal resolution is 1280 [px], and the width of the display target component A is 230 [px]. In this case, the actual width of the component A is 250 × (230/1280) = 44.9 [mm].
When such processing is performed, the GUI design data shown in FIG. 5A can be replaced with the actual size.

  In this way, the software creation apparatus according to the present embodiment detects that there is a component that violates the coding convention by comparing the result of converting the GUI design data into the actual size and the coding convention. For example, if the type of component A is “button” and there is a coding rule that “the horizontal width of the button on the external display is 45 mm or more”, it is determined that the component does not satisfy the rule.

When the component arranged on the form does not satisfy the convention, a warning to that effect is presented to the software developer through the input / output unit 101. The warning may be output to a console screen, for example, or may be output by a dialog or the like. Moreover, you may output to a log.

<Process flowchart>
Next, a processing flowchart for realizing the functions described above will be described.
FIG. 6 is a flowchart of the coding check process performed by the software creation apparatus according to the present embodiment. The process is executed by the convention check unit 105 based on a user instruction (for example, at the timing when the check function is activated in the development environment).

  First, in step S11, the display data acquired by the resolution acquisition unit 104, that is, the display resolution and screen size used for display are acquired. In the present embodiment, information about the display built in the mobile terminal 200 and the display 310 included in the in-vehicle terminal 300 is acquired. As described above, the display data may be acquired manually as described above, or may be acquired from a plurality of preset values.

Next, in step S12, GUI design data acquired by the design unit 102 is acquired.
Next, in step S13, the actual display size when the user interface screen is displayed on the external display is calculated. Specifically, among the display data, for the display whose type is “external”, the actual size and resolution are acquired, and the size of the component is calculated by the method described above.
Next, in step S14, by comparing the calculation result with the coding convention, it is determined whether there is a component that violates the coding convention. As a result, when there is a non-conforming component (step S15-No), the process is shifted to step S16, and the result is presented. If all components conform to the coding standards, no warning is given and the process ends.

  As described above, the software creation apparatus according to the first embodiment uses the information about the display externally connected to the target device, not the display of the target device, and the size of the component that is actually displayed is Determine whether the rules are met. This makes it possible to determine conformity / non-conformance of components based on how the software user actually sees the screen, and to ensure usability.

(Second embodiment)
The second embodiment is an embodiment that emulates the screen when the design target form is output to the display 310 and presents the screen displayed on the display 310 to the software developer in actual size. .
Since the configuration of the software creation apparatus according to the second embodiment is the same as that of the first embodiment, the description thereof is omitted, and only the parts different in processing will be described.

  In the second embodiment, the size and resolution of the display in the development environment (that is, the display used by the input / output unit 101) are retained and used for emulation. FIG. 7 is an example of display data in the second embodiment. Display information in the development environment is added to the data.

In the second embodiment, the size of the emulation screen is calculated using the actual size of the target component on the display 310 calculated in step S13.
For example, the actual horizontal size of the display used by the input / output unit 101 is 480 [mm], the horizontal resolution is 1280 [px], and the actual size of the display target component A on the display 310 is Consider the case of 44.9 [mm]. In this case, the size of the component for reproducing the actual size on the display 310 is 1280 × (44.9 / 480) = 120 [px]. Further, the arrangement position (coordinates) of the component in the emulation screen can be calculated in the same manner.

  The emulation screen generated in this way is presented to the software developer through the input / output unit 101. FIG. 8 is an example of an emulation screen output on the display of the development environment. The generation of the emulation screen can be executed at an arbitrary timing as long as display data and GUI design data are input.

According to the second embodiment, a software developer can perform development while confirming on the development environment a screen having the same size as that displayed on the display 310.
In the present embodiment, the emulation screen is generated for the display 310, but the emulation may be performed for the screen of the mobile terminal 200 by the same method.

(Modification)
The description of each embodiment is an exemplification for explaining the present invention, and the present invention can be implemented with appropriate modifications or combinations without departing from the spirit of the invention.

  For example, when a screen is exchanged between the mobile terminal 200 and the in-vehicle terminal 300, conversion that affects the screen design may be performed. FIG. 9 is an example of screen conversion when the aspect ratio is different between the display of the portable terminal 200 and the display 310. In this example, the form is arranged so that the height in the vertical direction fits the screen, and the area is complemented for the area outside the dotted line. As described above, when region complementation or enlargement occurs, the actual size on the display 310 may be calculated in consideration of the conversion.

  Further, as illustrated, the display data need not necessarily include all of the vertical and horizontal sizes and the vertical and horizontal resolutions. For example, only the resolution may be defined, and the remaining conditions (minimum required vertical and horizontal sizes) necessary to satisfy the coding convention may be presented at the time of execution. The reverse is also true.

  Moreover, in each embodiment, although the example which performs a check process based on a user's instruction | indication was given, you may perform the process of FIG. 6 in real time. For example, it may be possible to detect that the layout of the component has been changed and automatically execute the check.

  Moreover, in each embodiment, although the pixel was illustrated as a resolution, you may use another unit. For example, Density-independent Pixels (DIP) or Scale-independent Pixels (SP), which are pixel units that do not depend on the screen density of the terminal, or other units may be used.

DESCRIPTION OF SYMBOLS 100 Software creation apparatus 101 Input / output part 102 Design part 103 Storage part 104 Resolution acquisition part 105 Contract check part 106 Code generation part 200 Portable terminal 300 In-vehicle terminal 310 Display

Claims (9)

Check whether the software running on the first computer that can output the screen to the first display, which is the built-in display, and the second display, which is an externally connected display, has a screen interface that conforms to the regulations. A user interface evaluation device for
Resolution acquisition means for acquiring the actual size and resolution of the second display;
Design information acquisition means for acquiring information about components arranged on the user interface screen of the software;
When the software is executed on the first computer and the user interface screen is output to the second display, a component whose appearance condition on the second display does not satisfy a predetermined condition is Detecting means for detecting the presence of
A user interface evaluation device. The condition relating to the appearance is a condition relating to an actual size when the target component is displayed on the second display.
The user interface evaluation apparatus according to claim 1. The predetermined condition is a minimum value of any of a size of a character included in the component, a height of the component, a width of the component, and an interval between adjacent components.
The user interface evaluation apparatus according to claim 2. A third display,
An emulation means for generating an emulation screen, which is a screen emulating the result when the user interface screen is output to the second display, and outputting to the third display;
The user interface evaluation apparatus according to claim 1. The resolution acquisition means further acquires the actual size and resolution of the third display,
The emulation means generates the emulation screen with the same actual size as the second display.
The user interface evaluation apparatus according to claim 4. When the detection means detects that a component that does not satisfy the predetermined condition is included in the user interface screen, the detection means further includes warning means for warning the user.
The user interface evaluation apparatus according to claim 1. The first computer is a mobile terminal;
The second display is a display included in the in-vehicle device.
The user interface evaluation apparatus according to claim 1. Check whether the software running on the first computer that can output the screen to the first display, which is the built-in display, and the second display, which is an externally connected display, has a screen interface that conforms to the regulations. A user interface evaluation method performed by the user interface evaluation device,
A resolution acquisition step of acquiring the actual size and resolution of the second display;
A design information acquisition step of acquiring information about components arranged on the user interface screen of the software;
When the software is executed on the first computer and the user interface screen is output to the second display, a component whose appearance condition on the second display does not satisfy a predetermined condition is A detection step for detecting that there is,
A user interface evaluation method including:   The program which makes a computer perform each step of the user interface evaluation method of Claim 8.

Images