-
Introdução e aspectos teóricos
-
-
O uso do computador para ensino tem sido relatado como de poderoso efeito
no aprendizado. "Educadores necessitarão dele para construir milhares
de lições - usando software - em milhares de diferentes,
não-relatados, campos. Qualquer um pode escrever um livro texto...,
se armar-se de uma vídeo câmara e uma boa ferramenta de desenvolvimento
de software, pode ser capaz de construir um software educacional multimídia".
-
O software INDIE, desenvolvido e usado na ILS, é uma ferramenta
de construção de programas educacionais. O estudante dispõe
de uma grande variedade de escolhas e sofre críticas por suas escolhas.
-
O tópico básico do artigo é o problema de construção
de ferramentas para autores que têm pouco envolvimento com programação
e que têm em mãos um modelo bem representado do domínio
de aplicação, sem significativa reimplementação
para cada estágio do projeto. As dificuldades e soluções
são aqui relatadas.
-
-
INDIE: o que os estudantes vêem
-
-
INDIE constroi um tipo particular de programa educacional,
baseado em caso, no estilo aprendendo por executar, e um programa elaborado
na forma de um Cenário Baseado em Tarefas - GBS. Um GBS é
um mundo simulado em que estudantes têm de executar tarefas, usando
sua percepção crítica, conhecimento etc. Aos estudantes
é dado uma situação inicial, ferramentas específicas
para coletar e gerenciar informações e uma forma de comunicar
seu conhecimento e suas alegações - afirmações.
O sistema interage com o mesmo, colocando situações práticas,
um vídeo, criticando enfim.
-
A ferramenta INDIE constroi uma certa sub-classe
de um ambiente de aprendizado GBS que está centrado em torno de
tarefas de diagnóstico. Aos estudantes, se apresenta um problema
urgente e se solicita uma solução - diagnóstico. Após
uma análise do caso, os estudantes devem dar uma afirmação
sobre o mesmo e relatar aquilo que evidenciaram para prová-la.
Ao longo deste percurso, para obter a solução, os mesmos
podem pedir ajuda e navegar um hipertexto multimídia ricamente indexado
na rede, chamado de sistema ASK. A idéia central de tal sistema
é que uma idéia dá origem a outros quesitos importantes,
questões do tipo "follow-up"... tal como: Se o vídeo clip
menciona vulcões, questões do tipo: "O que é Magma?'
estarão relacionadas.
-
#O artigo apresenta, com detalhes o exemplo acima.#
-
-
Modelando o domínio
-
-
"Para ter um estudante aprendendo sobre um dado domínio,
os autores devem ser capazes de modelar o mesmo em software. Um modelo
sólido dá aos estudantes a oportunidade de interação
com tempo de pensamento, assim como se fala e dá ao GBS uma
boa base para remediar os estudantes." O que os autores devem fazer então?
Devem necessitam de ferramentas para modelar o mundo, prover realimentação
para estudantes e deixar os estudantes terem acessos ao conhecimento, de
forma escalonada. Se o programa é exatamente uma coleção
de telas com botões que as conecte, cada adição de
cenários ou testes requererá linearmente mais informação.
Assim temos de definir o que como o projeto INDIE construirá e quem
construirá?
-
-
O processo de projeto do GBS - Cenário baseado
em tarefas
-
-
Já foram construídos 8 GBS com o uso
do INDIE. Baseado nestas experiências, já se pode enumerar
as tarefas básicas e os estágios de uso da ferramenta:
-
1. Pre-tool: os autores coletam informações
relativas ao domínio com experts e livros em preparação
para fazer todo o projeto - trabalho em cima de anotações
pessoais;
-
2. Storyboard: autores antecipam concretamente o
que o programa irá tratar. Uso de anotações pessoais
ou PowerPoint para conceber uma sequência linear de telas, cada uma
delas com 1ou 2 botões de mouse na demonstração. Após
definição completa, testes são executados;
-
3. First Walktrough: Autores animam seus "storyboards"
- neste ponto fazemos um modelo em tamanho natural de alta fidelidade da
interface. Para projetos sem-ferramenta, isto pode ser feito no Director
ou Supercard, trabalhando botões, alguns movimentos e arte funcional.
-
4. Protótipo do primeiro cenário: Um
cenário completo e próximo do final é construído.
As partes mais difíceis são definidas (tal como os testes
e a estrutura para críticas), mas a aplicação geralmente
suporta 2 ou 3 caminhos diferentes para caminhar através do conteúdo
- demos, geralmente. A aplicação é implementada na
plataforma final de apresentação.
-
5. Shrinkwrapped System: este é o sistema
final. Todo o conteúdo está disponível, todos os testes
executados, o criticador está completo e não há mais
material a ser incorporado ao sistema.
-
É importante notar que diversos projetos acabam
por não passar por todas as fases e não chegam a serem concluídos.
-
-
INDIE 1.0 - uma abordagem dirigida pelo modelo:
-
-
Aqui os autores apresentam um modelo inicial que
não deu bons resultados... Nesta implementação, a
forma de tratamento do modelo foi dividida em diferentes módulos:
-
- The problem selector: estudantes escolhem um cenário
para trabalhar no vulcão - ou seja, a montanha que vão analisar;
-
- The lab: estudantes executam testes e conversam
com especialistas no assunto, coletando informações;
-
- The Argument Construct: estudantes fazem afirmações
para seus clientes na simulação, sugerindo ações
a serem tomadas ou diagnósticos;
-
- The Critiquer: estudantes têm realimentação
do clentes.
-
Os problemas desta versão:
-
- versão ficou muito restritiva: a construção
de módulos de representação do modelo não trabalhava
bem (os criadores implementavam telas de apresentação no
PowerPoint, por exemplo e quando iam implementar no INDIE tinham de entender
o modelo de representação do mesmo e construir objetos neste)
-
- na construção os autores precisavam
especificar as ações associadas com cada botão, requerendo
muito tempo para criação, ou seja, a rápida prototipação
ficou difícil - a saída para muitos foi construir um caminho
interativo no Supercard, sem um modelo específico e depois usar
o INDIE.
-
-
A dificuldade com os modelos em tamanho natural:
-
-
"O problema de se construir um modelo usando o Supercard
ou o Director é que para levar tal modelo implementado para outro
software requer uma re-implementação do programa na nova
ferramenta - provavelmente o INDIE."
-
"Isto torna claro que é necessário
tomar os originais das mãos dos autores e colocá-la nas mãos
dos programadores. Ao mesmo tempo, nós temos de preservar tais originais
de informação de modelos que têm o que necessitamos."
-
-
INDIE 2.0: Se não se pode derrotar o Supercard:
-
-
Assim, pode-se enumerar os problemas com o INDIE
1.0 que precisam ser tratados:
-
- Autores devem manusear uma dada visão que
necessitam, enquanto manipulam o modelo;
-
- a rápida prototipação da idéia
ficava difícil e consumia muito tempo;
-
- autores precisavam duplicar esforços entre
a construção do protótipo e seu produto final.
-
-
Editando interfaces simples:
-
-
"Para dar aos autores a visão do que procuram,
nós podemos ir construindo uma interface, inteiramente separada
do processo de construção da representação
do modelo." Interfaces agora são construídas como o Supercard
gosta,com botões, imagens e vídeos. Autores podem arrastar
diferentes widgets, redimensioná-las, mudar seus atributos
e testá-las. Widgets podem ser agrupadas em layers,
que podem ser apresentadas ou não, tal como uma unidade, dando aos
autores a possibilidade de reuso de telas e de sub-telas.
-
Para diminuir esforços e dispêndio de
tempo na edição, a interface numa aplicação
INDIE pode ser quebrada em 3 classes:
-
- apresentar ou não uma tela ou uma sub-porção
da tela;
-
- apresentar um movie;
-
- fazer uma ou mais questões ASK visíveis
na tela como botões clicáveis.
-
Os autores criam listas de respostas a eventos
e entram as mesmas numa tabela associada com eventos, ligada com telas,
filmes e questões de auxílio, de forma a solucionar o problema
de montagem de uma lição. Os autores não precisam
conhecer qualquer sintaxe ou construir uma lista de uma lista de comandos
para sua linha de pensamentos.
-
-
Modgets:
-
-
Triggers são usados para construção
das navegações, introduções e conclusões.
Eles não são suficientes para respostas mais complexas necessárias
em softwares educacionais. Assim, os autores propõe o uso de uma
associação de widgets com model: modgets, que
são widgets que têm uma interação com
a interface pré-definida. Elas apresentam o que está acontecendo
no modelo para certos tipos de objetos: questões e respostas
- neste caso, em particular.
-
Quando um estudante clica num botão de questão,
a resposta para a questão que o botão representa é
declarada. Um visualizador de respostas então apresenta o meio que
deve ser adequado, enquanto que o visualizador de questão apresenta
a questão seguinte e tratada como follow-up. Questões
e respostas são objetos do modelo que são autorizados separadamente
com a ferramenta da base de dados.
-
Aqui fica claro a estrutura dada à ferramenta:
2 widgets básicas que podem ser usadas para que o autor componha
toda a interface: a question-viewer e a answer-viewer. Tratados
no contexto com modgets, pelos autores.
-
Há outras modgets:
-
- para possibilitar aos estudantes manipular
e editar listas de ponteirso nos notebooks - um ponteiro é uma sentença
ou textos que resumem o conteúdo do meio usado ou descrevem os resultados
de testes. - notebooks modget
-
- glossary modgets;
-
- trash modgets;
-
-status argument modgets.
-
Todas as modgets indicam o estado do modelo
e são realmente similares a controladores de visão do modelo
- model-view-controllers.
-
-
Representações de escala:
-
-
A intenção das modgets é
abaixar a representação dos autores em estágios de
projeto. Quando se faz uma modget apresentar textos ou filmes, os
autores estão realmente construindo parte dos modelos que irão
necessitar ao longo da execução.
-
Ao longo do projeto, eventualmente, se usam as widgets
combinadas com os triggers condicionais, por exemplo, quando
se elaboram os testes, já que a visão, neste caso, é
muito variada.
-
-
Entendendo os comportamentos condicionais:
-
-
Em fases iniciais do projeto, autores tendem a construir
interfaces para não-interação com as modgets, que
trabalham simplesmente com as interfaces do Supercard: pressione um botão,
veja um filme e então coloque suas questões. Nesta forma
de manuseio, os autores podem rapidamente construir um caminho para demos,
mas, não constuir e reconstruir modelos.
-
Com o aumento de complexidade, autores necessitam
fazer a interface responder condicionalmente aos cliques, mas, um dos propósitos
da experiência INDIE 1.0 é fazer a duplicação
de esforços dos autores ser a menor possível.
-
Há diferentes formas de condicionalidade em
INDIE:
-
- apresentar diferentes introduções
e conclusões quando um cenário inicia ou encerra;
-
- apresentar diferentes filmes de críticas
ou avisos dependendo do que foi omitido, dos conflitos ou das irrelevâncias
apresentadas pelos alunos;
-
- apresentar diferentes resultados de testes e auxiliar
nas questões, dependendo do atual cenário em que o estudante
está.
-
-
Comentários pessoais: Pode-se
notar uma diferença interessante neste projeto do projeto clássico
de interfaces: aqui, os autores associam os eventos a determinadas situações
num dado modelo que produz uma resposta dependente de uma estrutura definida
- o modelo - e só depois apresentam um dado resultado na tela na
forma de uma saída válida - um filme, etc. Cenários,
testes e modelos dos objetos não aparecem na tela se não
forem associados a modgets.
|