We have recently reviewed the needs for using “outside” technologies for the widgets/plugins we are developing within this project.
The issues involved in the decisions are as follows:
- To have working solutions at UoR, so must work within Blackboard (bb)
- To have solutions that works for most institutions within HE as possible
This is a bit of a balancing act, as the two do not compliment each other, but we will try / have tried to accommodate as best as possible for both sides.
1. Video plugin
The back-end is developed using an in-house modified version of the open source dropbox 2 server available at https://turin.nss.udel.edu/wiki/dropbox/doku.php It provides a good solution for delivering large files to users. The modified version delivers embed scripts for users, which enable them to use the videos within any webpage they have editing right of, including Blackboard pages.
2. Tagging and recommender
The tagging widget will be based on a 3rd part tagging API (such as delicious) and will be embedded into blackboard using building blocks (b2). By utilising an outside API we ensure that the widget won’t rely on pure internal BB functionalities. There could be an argument against the use of B2, as it could be seen as integrating using a BB methodology, but B2s are merely wrappers that provide a view through BB, and it is the opinion of the development team, that it will be possible to code this in a way that is transferable using the MVC paradigm (see http://goo.gl/McpS).
3. ePortfolio plugins
The ePortfolio plugins, when reading the proposal, has to use the already existing BB ePortfolio system, as the aim is to enhance the already used system.
4. Widget APIs
The team started out evaluating different widget APIs which might be valuable for the project, and this culminated at the JISC Cetis meeting in Bolton where Google’s open social API, IMS LTI and Apache’s Wookie API was presented as good possible solutions.
The team already knew that Opensocial wasn’t going to be practical for any of the functionalities of the project, as this project doesn’t involved any data sharing with social networks.
Regarding Wookie, the team has evaluated the option, and the benefits of developing a Wookie app placeholder within BB using B2 for placing the functionalities aren’t clear and definitely not viable with the time available for development within the project. Especially when other providers, such as Google and Netvibes, provide APIs and servers that, if not fully, closely match the functionalities of Wookie (except for communication using Wave API). This is only highligthed when it is considered that when using Wookie the institution has to run a Wookie server in-house, which might be difficult to sustain under the current economical climate.
It is the belief of the development team that the B2s can modified to use the Google and/or Netvibe APIs as they like B2 only provide wrappers for normal web code providing a specialised view.