Remarques intro #1
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
*1e paragraphe, concernant le public visé je dirais plutôt "destiné aux débutants en programmation et/ou en Basic CASIO, à partir de X ans et jusqu'à au moins X ans." pas "à tous les niveaux etc vétérants etc".
*2nd paragraphe : pas de négation au début d'une intro ! Je mixerais les 2nd et 3e paragraphe pour qu'ils disent en gros "on va vous donner le nécessaire pour les concepts généraux de la programmation, leur appliquation en Basic + qq astuces pour que vous ayez ce qu'il faut pour faire un jeu. Si vous êtes + curieux => forum".
*4e paragraphe : pas d'accord pour parler de code dans l'intro. On explique ce que c'est seulement plus tard. Donc conseil pertinent, mais pas à cet endroit du tuto.
*Pargraphes restants : oui très bonne idée de préciser les prérequis matériels (Mais est-il nécessaire de préciser les modèles NON compatibles après avoir déjà ciblé les modèles OK ?). Faut-il étendre à d'autres prérequis ? Parler du temps estimé, du fait qu'il n'y a pas besoin d'être en seconde ni d'être fort en physique etc ?
*Dernier paragraphe : pas sûr qu'il y ait besoin de parler du contenu dans l'intro générale ? Je préfère un message type "c'est parti !" ;)
Merci pour ces retours !
Pas de problème avec moi, change pour quelque chose qui te plait mieux.
Dans ce cas inverse le sens de la phrase. Je vois l'intérêt de ne pas commencer par une négation, mais c'est important de dire ce qu'on couvre et ce qu'on ne couvre pas. C'était pensé comme §1 voilà ce que c'est et §2 voilà ce que ça n'est pas.
Je ne vois pas de meilleur endroit, le reste commence trop vite dans le technique. On peut reformuler en "n'hésite pas à t'inspirer de tes jeux préférés", mais ça perd de son sens (ça fait "inspire-toi du gameplay").
Et puis bon, c'est un peu tiré par les cheveux je trouve. Si tu parles de "concepts généraux de programmation" dans le paragraphe 2 ou 3, tu peux largement te permettre de parler de "code" ou "programme" plus bas.
Oui. C'est cité brièvement en off de la liste, et ça évitera à quelqu'un de se dire ou bien "je vais pousser quand même pour voir si ça marche" ou bien "c'est peut-être pas à jour pour les ClassPad" et de n'arriver à rien avec. Les gens pas concernés l'oublieront aussitôt, c'est pas le même statut que du bloat dans le tutoriel en lui-même.
Déjà couvert par le premier paragraphe !
Je trouve l'intro générale pas très motivée, si tu ne l'introduis pas ici je pense qu'il faut au moins annoncer dans I-1 que le code commence après, sinon tu vends un tuto de programmation et tu fais un chapitre complet sans programmation. Donner un peu de vision sur la suite devrait être naturel.
OK pour les 2 premiers points.
3e point : à quoi sert de dire d'aller lire des programmes avant d'avoir appris à la lire ?!? Donc pour moi il faut conseiller de s'inspirer des autres à partir de fin partie III ou partie IV. Avant ça, c'est un conseil qui sera lu et oublié selon moi, en plus d'éventuellement distraire ou complefixier.
Concernant l'intro de I-1 à la fin, ça me dérange dans le sens où l'on quitte l'aspect "page de garde". Si l'on fait ça, alors on ajoute quelques lignes sur le plan général, ou on glisse le sommaire dans un spoiler. Des phrases pour introduire la suite c'est important mais là on est sur la devanture du tuto. Autre solution : mieux introduire I-1 à son début.
J'imaginais une page beaucoup plus graphique avec des zones bien découpées ou avec des titres plus identifiables du type "objectif", "public visé", "prérequis", "exemple de résultats", "sommaire" qui en un coup d'oeil permettraient à chacun de se situer par rapport au contenu attendu. A la limite il faurdrait que ça tienne sur un A4 ! ^^
Je pense que si tu le dis en fin de chapitre ce sera pas lu et encore plus vite oublié. xD
Évidemment c'est un conseil pour le futur, mais attendre la partie III pour en parler contredirait l'objectif que chaque fin de partie soit possiblement la fin du cours. J peux imaginer par contre l'aborder à la fin de partie I en citant des programmes simples qu'on peut consulter pour en apprendre un peu plus, puis pareil à la fin de la partie II avec des programmes un peu plus compliqués, etc.
Je vois où tu veux en venir, même si je ne l'avais pas structuré avec cette idée en tête. Je pense que la solution de modifier un peu I-1 me plaît bien dans ce contexte.