[This post is made for project presentation.]
1. Navigational Restriction
Kids tend to have an exploratory behavior. They will touch everywhere on the screen to try everything. They can't distinguish between the app content and advertisements. Sometimes advertisers make use of this behavior and this is not recommended in our opinion. We suggest that, firstly, software developers should not make use of children's innocent act to make profits. However, if it is indeed crucial or important to add such links as extra information, the user should be warned first. The screenshot above from "Spot Goes to School" shows a good example. It should be the same case for links to download page of additional apps (for example, full version of a free game).
Restricted navigation can also be considered in terms of depth and in terms of State Machine, it should be kept to a minimum. Preferably we think a depth of two is quite sufficient, one first or presentation level and a second gameplay–level. An example where restricted navigation has been considered in the design process are those navigational page menus to jump between pages of a children's book. Interactive books require more navigation depth and often several pages or states. If children are supposed to be able to handle an interactive book by themselves, they need menus to overlook and understand the navigational depth and how to swap between them easily. Every page should be displayed in a proper way and jumping between pages , example by touching pictures of pages, should be made easy. Also if a child is exiting/quitting the application or book, it should be supported and easy to go back to the page where they left, without having to go through half of the book or every page of it.
2. Feedback (Positive/Continuous)
It is important to always or whenever possible, use feedback, to encourage and entertain gameplay with learning.
Such feedback could be text, auditory, haptic, graphical/visual/animation or combinations of any and preferably positive. Positive feedback leads to stronger retention of memories, because it is based on positive experience and it invokes emotions, it makes it easier to recall from memory then. Such feedback should be real-time, meaning that it should be not giving out only and the end of a game stage, but after each (correct) action done by the user. Another reason is that kids have no anticipation, and they want feedback on the spot; So if nothing happens after each action taken, they soon get bord. Textual information or dialog windows are not recommended since most kids can't read and sound or auditory feedback should be tested to see if the sound is appropriate and that the cause is understood.
Another example of feedback that should be avoided is loading bars and screens. The programe should do something to entertain the kid and at the same time buffer in the background of the application.Example play music and show video while waiting. Kids don't understand the concept of buffering or loading, so they will most likely not understand what's going on lose their attention.
3. Support Multitouch (Error Prevention)
Due to physical limitation of kids and their interaction style, they tend to be too curious to follow instructions and they want to try things on their own. Most of the time they use several fingers (accidentally) at once instead of one, which is expected by the system and also holding and grasping the device differently than adult users. Therefore it's important to support multitouch but make clear with appropriate instructions, (see below, guideline 4) what action or movement that is expected to complete the task.This is related to error handling as well, it's not their fault that they will try to use several fingers at once and or move/touch several object at once. It should therefore be supported and not considered as wrong or failing. It's also about restricting the number of active controls to the minimum and highlight them (affordance) so that the users understand that something will happen if they are touched.
4. Proper Instructions
Hint users about what is expected by a certain task.
By using metaphors/graphical representations, or animations (for example a demo during which no interaction is allowed), children are well informed about how a task should be completed. In such cases, visual/audio instructions are preferred than text only, since most kids can't read.
A negative example:
(why learn numbers when they can already follow the number sequences?)
Another concern is that, with proper instructions given, kids can be independent from parents' aid and presence, to increase the pleasure of completing a task by oneself. This is important for self confidence and personal development of children, by making them feel more independent.
5. Simplicity
Developers should always try their best to restrict the number of controls available to the most necessary and important functions. Also, graphics should be kept simple, with the most important button made obvious and enlarged. By mentioning simplicity here we don't mean to reduce the use of color/attractive visual elements, what we suggest is that they should be arranged properly to highlight the most (probably the only) important function(s); but still, things should be made interesting. Also they should be used to distinguish between interactive parts from static content display.
Good graphical representations or metaphors of real world objects would help children to identify with the object better in real life, enhancing their learning process. Conversely, a badly-represented object within the app can only serve to confuse the child and hinders their learning. of the real world.
7. Design for All (Kids)
We are not talking about universal design here. However, designers should try their best to take the greatest common ratio of all kids' interest, regardless of their language, culture.
The key point is, to keep everything simple, bright and interesting.
A good example of "design for all kids" here is Teletubbies, the worldly well-accepted children's programme by BBC&Ragdoll. This is not an application, but has good concepts we can borrow. (By the way, there is an Teletubbies app in store: Teletubbies: My First App. Unfortunately we didn't go through any evaluation of it.)
Here is another good example: Kids' Song with Dancing Cat. It is basically a simple collection of videos, with not much interaction with user. But it is so interesting and visually attractive that, users cant help dancing with it!
Also, it is good idea to build applications based on existing stories/characters.
8. Concept
A negative example, as shown in one of the earlier post, is a game called "iWriteWords". Where the epic fail is, it is using numbers to teach users how to write numbers!
In general, developers should not take for granted that children know about certain things, like numbers, as well as the default position of home/info buttons (usually top left and right corners of the screen). It is crucial to set up the correct concept at earlier stage of design. Such discussion may be, what are the good things we shall teach a kid? What are good ways for kids to learn stuff through gameplay? Because things appeared normal to adults are not so to kids; they are a piece of blank paper, yet to be painted by what they see.
9. Observe Design
We suggest that when developing a kids application, a developer/designer should follow or use a user-centered design approach, to involve kids and get direct feedback, continuously during the whole design process. Just like "the best way of testing a todo-manager application is to use it yourself", to test a kids application, the best way is to let kids themselves play with it! It is also important for discovering conceptual design, and interaction problem during early stage of development.
Restricted navigation can also be considered in terms of depth and in terms of State Machine, it should be kept to a minimum. Preferably we think a depth of two is quite sufficient, one first or presentation level and a second gameplay–level. An example where restricted navigation has been considered in the design process are those navigational page menus to jump between pages of a children's book. Interactive books require more navigation depth and often several pages or states. If children are supposed to be able to handle an interactive book by themselves, they need menus to overlook and understand the navigational depth and how to swap between them easily. Every page should be displayed in a proper way and jumping between pages , example by touching pictures of pages, should be made easy. Also if a child is exiting/quitting the application or book, it should be supported and easy to go back to the page where they left, without having to go through half of the book or every page of it.
2. Feedback (Positive/Continuous)
It is important to always or whenever possible, use feedback, to encourage and entertain gameplay with learning.
Such feedback could be text, auditory, haptic, graphical/visual/animation or combinations of any and preferably positive. Positive feedback leads to stronger retention of memories, because it is based on positive experience and it invokes emotions, it makes it easier to recall from memory then. Such feedback should be real-time, meaning that it should be not giving out only and the end of a game stage, but after each (correct) action done by the user. Another reason is that kids have no anticipation, and they want feedback on the spot; So if nothing happens after each action taken, they soon get bord. Textual information or dialog windows are not recommended since most kids can't read and sound or auditory feedback should be tested to see if the sound is appropriate and that the cause is understood.
Another example of feedback that should be avoided is loading bars and screens. The programe should do something to entertain the kid and at the same time buffer in the background of the application.Example play music and show video while waiting. Kids don't understand the concept of buffering or loading, so they will most likely not understand what's going on lose their attention.
3. Support Multitouch (Error Prevention)
Due to physical limitation of kids and their interaction style, they tend to be too curious to follow instructions and they want to try things on their own. Most of the time they use several fingers (accidentally) at once instead of one, which is expected by the system and also holding and grasping the device differently than adult users. Therefore it's important to support multitouch but make clear with appropriate instructions, (see below, guideline 4) what action or movement that is expected to complete the task.This is related to error handling as well, it's not their fault that they will try to use several fingers at once and or move/touch several object at once. It should therefore be supported and not considered as wrong or failing. It's also about restricting the number of active controls to the minimum and highlight them (affordance) so that the users understand that something will happen if they are touched.
4. Proper Instructions
Hint users about what is expected by a certain task.
By using metaphors/graphical representations, or animations (for example a demo during which no interaction is allowed), children are well informed about how a task should be completed. In such cases, visual/audio instructions are preferred than text only, since most kids can't read.
A negative example:
Another concern is that, with proper instructions given, kids can be independent from parents' aid and presence, to increase the pleasure of completing a task by oneself. This is important for self confidence and personal development of children, by making them feel more independent.
5. Simplicity
Developers should always try their best to restrict the number of controls available to the most necessary and important functions. Also, graphics should be kept simple, with the most important button made obvious and enlarged. By mentioning simplicity here we don't mean to reduce the use of color/attractive visual elements, what we suggest is that they should be arranged properly to highlight the most (probably the only) important function(s); but still, things should be made interesting. Also they should be used to distinguish between interactive parts from static content display.
6. Graphical Representation/Metaphor
Good graphical representations or metaphors of real world objects would help children to identify with the object better in real life, enhancing their learning process. Conversely, a badly-represented object within the app can only serve to confuse the child and hinders their learning. of the real world.
7. Design for All (Kids)
We are not talking about universal design here. However, designers should try their best to take the greatest common ratio of all kids' interest, regardless of their language, culture.
The key point is, to keep everything simple, bright and interesting.
A good example of "design for all kids" here is Teletubbies, the worldly well-accepted children's programme by BBC&Ragdoll. This is not an application, but has good concepts we can borrow. (By the way, there is an Teletubbies app in store: Teletubbies: My First App. Unfortunately we didn't go through any evaluation of it.)
 |
| Teletubbies, it works for all kids! |
Here is another good example: Kids' Song with Dancing Cat. It is basically a simple collection of videos, with not much interaction with user. But it is so interesting and visually attractive that, users cant help dancing with it!
Also, it is good idea to build applications based on existing stories/characters.
8. Concept
A negative example, as shown in one of the earlier post, is a game called "iWriteWords". Where the epic fail is, it is using numbers to teach users how to write numbers!
In general, developers should not take for granted that children know about certain things, like numbers, as well as the default position of home/info buttons (usually top left and right corners of the screen). It is crucial to set up the correct concept at earlier stage of design. Such discussion may be, what are the good things we shall teach a kid? What are good ways for kids to learn stuff through gameplay? Because things appeared normal to adults are not so to kids; they are a piece of blank paper, yet to be painted by what they see.
9. Observe Design
We suggest that when developing a kids application, a developer/designer should follow or use a user-centered design approach, to involve kids and get direct feedback, continuously during the whole design process. Just like "the best way of testing a todo-manager application is to use it yourself", to test a kids application, the best way is to let kids themselves play with it! It is also important for discovering conceptual design, and interaction problem during early stage of development.
No comments:
Post a Comment