Applications that exchange simple UGC must comply with the guidelines in this chapter.
If your application cannot comply with all guidelines in this chapter, then you must handle the UGC as rich UGC rather than simple UGC. In this case, you must comply with the guidelines in Chapter 7.4 Rich UGC instead of the guidelines in this chapter.
7.3.1 Using Simple UGC
Any feature that allows a user to specify individual other users who are not friends and send them simple UGC could potentially be abused for purposes of harassment. For this reason, it is prohibited in principle to implement any communication features that allow the user to transmit simple UGC individually to specified parties who are not friends. It is acceptable, however, to send simple UGC to specified parties who are not friends in the following cases:
- Exchanging simple UGC via local communication where the communication partner can be identified beforehand.
- Measures equivalent to those described in 7.4.5 Preventing the Exchange of Rich UGC with Offensive Users have been taken.
- When the UGC being exchanged is the system user name or a Mii nickname.
Contact Nintendo at support@noa.com if you want to send simple UGC to specific communication partners other than friends, but the above cases do not apply to your application.
It is generally acceptable to exchange simple UGC in StreetPass, because it is not possible to specify the communication partner beforehand when using StreetPass. However, it is prohibited to implement specifications that would tailor or otherwise customize the content of UGC depending on which specific non-friend communication partner it is delivered to. This is equivalent to sending content to a specific individual who is not a friend.
A design feature that allows UGC content to change after being delivered via StreetPass only to a specific communications partner would include, for example, setting a personal greeting for use in the StreetPass Mii Plaza. This kind of feature is prohibited as a general rule.
7.3.1.1 Prohibition Against Exchanging Simple UGC with Specified Parties Who Are Not Friends
Guideline Item |
You must not specify someone who is not a friend with whom to exchange simple UGC.
|
---|---|
Software to Be Tested |
Applications that exchange simple UGC.
|
Exceptions |
Implementations which exchange UGC corresponding to any of the following categories:
|
Test Method |
|
Pass/Fail Determination |
Passes if, in step 3, it is not possible to specify a communication partner who is not a friend and send simple UGC to that person.
|
7.3.2 Freely Composed Messages with Restrictions
This refers to users freely exchanging text messages that conform to restrictions 1 to 6 below. Your application must comply with all of the following if it exchanges this type of message with communication partners.
- Features that allow freely composed messages with restrictions to be used in text chat, message boards, and the like are prohibited. For example, it is prohibited to allow unrestricted communication that enables users to send multiple text messages consecutively to a communication partner in the manner of a chat program or a message board.
- A freely composed message with restrictions must be a string of no longer than 16 characters. Spaces are counted toward the character limit.
-
If the user is able to enter numeric characters, do not allow more than five numeric characters to be displayed on either screen, for a total of 10 numeric characters between both screens , at any given moment. This includes all freely composed messages with restrictions. The numeric characters that should be counted toward the five-character limit should be limited to the numeric characters on the software keyboard. Numeric characters exceeding the five-character limit are permitted in the following cases:
- Numeric characters contained in (for example) Mii nicknames, or in UGC created by other applications, do not count toward the five-character limit.
-
More than five numeric characters can be displayed on a single screen at the same time if they appear in names (user, character, or item names) that were input at different locations. For example, a user name entered initially in the application and item names entered later, totaling more than five numerals, can be displayed at the same time. For items other than names, the number of numerals must not exceed five in total. For example, if a name, interests, and a comment are entered at the same time and then displayed together on the same screen, the total number of numeric characters must not exceed five.
Specifications that allow users to create one message by stringing together multiple text items are not considered an exception to this rule. For example, applications are prohibited from allowing users to edit multiple text items on the same or consecutive screens, and from displaying them on the same screen on the receiving side. See also Figure 7-7 Unacceptable Examples: Cases Not Covered by Exception (b) of Restriction (3).
- Do not allow the “@” sign to be entered in strings. Contact support@noa.com if you are considering using the “@” sign.
- We recommend that your application prevent the recipient from receiving the same UGC many times. (For example, the application should display sent comments only once on the recipient’s system.)
- Do not enable redistribution of freely composed text with restrictions, with the exception of text used as names, such as user names, character names, or item names. For example, it is prohibited to allow redistribution of freely composed text with restrictions that users have entered as messages. If you are considering such a feature, please contact support@noa.com.
In addition to the above, consider ways to prevent users from offending other players and unintentionally revealing personal information when entering text in freely composed strings. This could be achieved, for example, by warning users that they are sending personal information when certain strings, such as street addresses or phone numbers, are detected.
Optional features, including specifying the number of input characters, restricting input of numeric values (0 to 9 [0x0030 to 0x0039], 0 to 9 [0xFF10 to 0xFF19], ⁰ to ⁹ [0x2070 to 0x2079] , ₀ to ₉ [0x2080 to 0x2089] , Ⅰ to Ⅻ [0x2160 to 0x216B], ⅰ to ⅻ [x2170 to 0x217B], ① to ⑳ [0x2460 to 0x2473 ], ⑴ to ⒇ [0x2474 to 0x2487], ⒈ to ⒛ [0x2488 to 0x249B ], ❶ to ❿ [0x2776 to 0x277F ], ➀ to ➉ [0x2780 to 0x2789 ], ➊ to ➓ [0x278A to 0x2793 ], and the @ symbols [0x0040 and 0xFF20]), and profanity-checking the entered text are provided with Nintendo’s software keyboard. For details, see the manual for the software keyboard.
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
Determination |
N |
i |
n |
t |
e |
n |
|
T |
a |
r |
o |
u |
|
|
|
|
|
OK. (Spaces are counted as one character.) |
N |
i |
n |
t |
e |
n |
d |
o |
|
K |
o |
u |
t |
a |
r |
o |
u |
Unacceptable (Because it consists of 17 characters.) |
任 |
天 |
堂 |
|
た |
ろ |
う |
|
|
|
|
|
|
|
|
|
|
OK. (Hiragana, katakana, and kanji each count as 1 character.) |
N |
i |
n |
1 |
0 |
1 |
8 |
8 |
9 |
|
|
|
|
|
|
|
Unacceptable (Because six or more numeric characters are entered) |
|
N |
a |
m |
e |
|
: |
N |
i |
n |
1 |
0 |
|
|
|
|
|
|
Example of two-line string |
B |
i |
r |
t |
h |
: |
1 |
8 |
8 |
9 |
|
|
|
|
|
|
|
|
M |
a |
r |
i |
o |
@ |
n |
i |
n |
t |
e |
n |
d |
o |
|
|
|
Unacceptable (Because it contains an “@” sign) |
7.3.2.1 Handling Freely Composed Messages with Restrictions
Guideline Item |
The application must appropriately support the use of freely composed messages with restrictions. |
---|---|
Software to Be Tested |
Applications that exchange freely composed messages with restrictions. |
Exceptions |
Implementations corresponding to any of the following:
|
Test Method |
|
Pass/Fail Determination |
Passes if all of the following conditions are met.
|
7.3.3 Images with Restricted Sizes
This refers to a type of image (such as planar maps), as shown in Figure 7-8 Example of a Map Editor Using No More Than 10x10 Tiles. If your application exchanges images with restricted sizes, you must allow no more than 10 horizontal or vertical tiles, to prevent users from writing telephone numbers or other personal information.
7.3.3.1 Handling Images with Restricted Sizes
Guideline Item |
The application must appropriately handle images with restricted sizes. |
---|---|
Software to Be Tested |
Applications that exchange images with restricted sizes. |
Test Method |
|
Pass/Fail Determination |
Passes if, in step 3, images larger than 10x10 tiles cannot be sent. |