I’m posting here some main points from the first day of the developers’ workshop that relate to scenario and prototype affordances, technical possibilities and limitations. This is going to be a bit technical – be forewarned!
iTEC Shells need to display widgets, and possibly other (legacy) shell components. Native Shells are locally installed applications or apps (eg. Yahoo! Widgets, Apple Dashboard; Opera Widget RT, Obigo Runtime; SMART Classroom Suite, Promethean ActivInspire). Web-based shells are in web pages and are executed in a browser (eg. Liferay, Drupal, Wikispaces wiki; Moodle, .LRN, ActiveProgress; iGoogle, Google Sites, NetVibes, Promethean Planet).
Widgets should be accessible from multiple shells (web, mobile, native shell), with access to same data and functionality (where relevant).
Widgets use the authentication of the host platform (Moodle etc.) which is a big bonus and makes user account management problems go away. Google Docs documents can be used via iframes (which can be widgetized) to do collaborative editing. Common Cartridge allows for embedding of content from another server to a shell.
Google Sites could combine eg. Google Docs, Google Maps and Picassa. Flexible access rights, template creation and sharing, free, UI localized. Use of 3rd party services may be a problem (can’t force pupils to use them; parents may also not give permission).
Response systems from Smart and Promethean can work anonymously or can be personalised (students login) and are then linked to the user profile.
Google App Inventor is an easy tool for creating Android apps (even children can do it). An alternative to widgets for mobile use.
Diagram of scenario development in WP2-WP3-WP4
The big picture of scenarios and prototypes has become more defined (see image). For the upcoming coordinator meeting we need to have some concrete implementations of scenarios. And in actuality we need to rewrite the scenarios and create several variations of them, since each bundle may be geared towards certain technology solutions. It does not make sense to clutter teacher guidelines with dozens of alternatives, but rather to do concise, focused guidelines for each variation. Eg. the “Recognizing informal learning” scenario could be implemented simply with an ActivInspire Studio file, or a Smart Notebook file, or a Moodle instance, or some 3rd party web service, or lots of other ways. Instead of putting everything together it makes sense to create a few variations that are similar to each other.
