Sharing reviews and ratings between educational web app stores

I’m just starting work on a new project to share “paradata” – things like reviews, ratings, comments and download/embed stats – between several new educational app stores being developed. The idea is to use an infrastructure developed in the US called the Learning Registry as the sharing network for this information, and to connect this with – initially – three web app stores.

The app stores are an initiative from the Open University to create store for UK Higher Education, ITEC, aimed at secondary schools across Europe, and the Widget Store created by the ROLE project aimed at independent learners and educators.

We’re working on EDUKAPP, which is a white-label open source web application store (based on Apache Wookie and Apache Shindig) that can be customised and deployed by organisations targeting different sectors and regions.

However, once you have multiple app stores – and the evidence so far is that different communities in education do feel you need this – then you fragment useful information such as download and embedding statistics, comments and ratings. So we want to make it possible to share this information across stores, so that if multiple stores are providing the same web app, they can pool this info and provide a better user experience.

A key aspect of this is how the data is formatted and exchanged using the Learning Registry; they have a subject-object model in JSON based loosely on Activity Streams that we’ll use as our starting point. However, the Learning Registry infrastructure is set up for sharing of metadata structures without any kind of de-duplication or post-processing, which means we have to be very careful about over-counting statistics and the like. I think we’ll have to encode in the actual software module we produce some conventions that will make it easier to aggregate things like download statistics without double-counting, for example.

The project name, incidentally is SPAWS – sharing paradata across widget stores and has been funded by JISC as part of its OER Rapid Innovation Programme. I’ll be posting more updates on it here so you can see how we get on.

 

 

Open Education: The Fifth Network

I’ve been reading some of the posts from Amber, David and Lawrie as part of open education week. One thing that strikes me about it all is the similarity to Ivan Illich’s idea of learning webs, which is based on connecting up networks of individuals and resources to share skills and support one another’s learning.

One of the weaknesses of Illich’s learning webs is the emphasis on the individual; the networks are essentially networks of individuals who are both the consumers and the products of learning. The learning opportunity itself is assumed to exist in the interactions between the members of the network rather than as a discrete product that can be traded in some manner independently of the individual who offers it.

This is a very compelling vision of a learning web, but its a simplification. In an open education marketplace, it still makes sense for individuals to group together to reduce duplication and costs, and to add value by capitalising on their strengths. Such groups will then produce more standardised, off-the-shelf opportunities at lower cost than the bespoke one-to-one interactions between individuals that are implied in the learning webs model. As such groups become more successful, they exert market power, such as promoting the market value of their offerings through things like tokens of status for achievement, backed by the reputation of the provider.

So before you know it, you get back to something like a formal education system dominated by some large providers, and a long tail of specialist training companies and individual tutors and coaches.

While its tempting to see the internet and social networks as providing the kind of disintermediation that would disrupt this type of market pattern, a quick look around reinforces the “long tail” view – while a global distributed market does enable a large number of very small providers to survive, it also tends to amplify the dominance of the very largest providers. Or, to put it another way, with the opening up of eCommerce networks you get a lot of individuals selling a couple of things on Etsy or eBay; but you also get Amazon selling pretty much everything. (So it perhaps shouldn’t be surprising that the institutions putting a lot of effort into open education and open education resources are typically the largest and most famous)

Is open education, therefore, rather than a distribution of education opportunity and provision to a network of peer learners, instead a short cut to a globalised education market dominated by a handful of huge institutions, with a vast army of freelancers trying to make a basic living on the margins?

How could you possibly not get here from there? Is the idea of learning webs a complete non-starter?

(I don’t know whether its necessarily a good or bad thing as such, but when talking about open education, and the possible demise of the formal education system as we know it, we need to be clear about the potential consequences.)

Perhaps we need to add a Fifth Network to any discussion of learning webs and open education: the regulatory system of exchange that mediates the interactions between members of the network. The default for this is the same kind of market that exists for other kinds of services, but other possibilities include vouchers, offsets as well as various kinds of supply-side mechanisms.

Its this network that determines the overall shape of the other four networks, and of the learning web as a whole.

Design challenges for user-interface mashups: user control and usability in inter-widget communications

I originally wrote this as a paper submission for WSKS 2011 as part of my work on the OMELETTE project, but decided to withdraw it – however I think it might be interesting given there is a lot of discussion at the moment around inter-widget communication and interactive mashups. Its probably worth reading this in conjunction with my post on Web Intents.

Design challenges for user-interface mashups: user control and usability in inter-widget communications

Scott Wilson

Abstract. Mashup platforms can expose a means for widgets to interact with one another; while there are communications protocols suitable for implementing this, a design challenge is how to provide users with the feeling that they are in control without being confronted with complex platform configuration. In this paper we discuss a number of approaches taken by projects to resolve this; either reducing platform complexity using metaphor, or in enhancing user control. One major issue is the lack of usability research in this space, particularly of the design metaphors commonly used by mashup solutions aimed at non-developers.

Keywords. Widgets, Inter-Widget Communication, Choreography, Mashups, Design, Usability, Accessibility

Introduction

Widgets, perhaps taking the place of portlets (Law, Müller and Nguyen-Ngoc, 2009) can be used as a building block of web dashboards and mashups, enabling users to construct personal workspaces consisting of multiple widgets talking to different backend services organized according to personal needs. In the literature of technology-enhanced learning, this is the focus of MashUp Personal Learning Environments (MUPPLE); in other domains we may describe this more generally as a user interface mashup (UI Mashup).

A workspace or dashboard can provide a range of features; for example it can support extension with additional widgets talking to backend services such as enterprise systems and social web services. It can also support user-managed layouts, for example enabling users to position widgets on the screen or to divide them among tabs.

However a number of projects that have used this approach considered that the absence of communication between widgets to be a significant limitation, and have developed solutions that extend either the capabilities of widgets, the capabilities of the containing platform, or both.

Reviewing prior approaches to inter-widget communication

Probably the most comprehensive analysis of inter-widget communication implementations and standards is that undertaken by Ivankovic and Zuzak (2011). However, in this paper we focus on high-level architecture and the challenges for users, particularly non-developers. In Wilson, Daniel, Jugel and Soi (2011, in press) we set out the following characterization of user-interface mashups involving inter- widget communications:

 Orchestrated UI mashups, where the interactions between the widgets in the mashup are defined using a central control logic;

 Choreographed UI mashups, where the interactions between the widgets in the mashup are not defined, but instead emerge in a distributed fashion from the internal capabilities of the widgets;

 Hybrid UI mashups, where the emerging behaviour of a choreographed UI mashup is modified by inhibiting individual behaviours, practically constraining the ad-hoc nature of choreographed UI mashups.

Orchestrated UI Mashups

For an orchestrated mashup, each communication channel between widgets needs to be explicitly declared by the user before there is any information flow. This can be done at design time or at runtime, and can use a range of metaphors, but in implementation results in a set of instructions to the orchestration control logic.

In the EZWeb project (see Lizcano, Soriano, Reyes and Hierro, 2008), the orchestration takes the form of a control screen where users create “channels” that link the outputs of widgets with the inputs of widgets. So, for example, a “Map” widget may have a “location” output, and a “Flickr Photo” widget may have a “location” input. The user can therefore make a connection between them.

The Gepetto prototype system also used a wiring model, but exposed this within events in the widget interface itself, for example allowing users to select the components of the widgets as sources and targets of communications (Zuzak, Krolo and Srbljic, 2008).

The Rooftop Marketplace system created by SAP for the FAST project used a direct wiring mechanism directly in the user interface, exposing input and output points of widgets to be connected by users with wires in much the same manner as the Yahoo! Pipes web interface (Hoyer, Gilles and Stanoevska-Slabeva, 2009).

The key challenge for orchestrated mashups is engaging the user in the active construction of the inter-widget communication. While “wiring” may be a fairly easy to understand metaphor for most engineers (and musicians, for example the Propellerheads Reason music software also uses this metaphor; see Villar, Lindsay, and Gellersen 2005), it is unclear if this would pose a challenge for general users.

Choreographed UI Mashups

In a choreographed UI mashup, the interactions between widgets are emergent rather than designed; for example, when a user adds a widget to a workspace or layout, it starts interacting with the widgets around it without any connections needing to be explicitly defined by the user. Each widget is therefore capable of independently sending and receiving communications and of acting on them

A common model for choreographed communication is a publish-subscribe messaging approach. In this model, widgets can subscribe to topics of interest (e.g. “location”) and send messages to topics. The runtime environment is then responsible for routing messages according to their topic.

The strength of this approach is that there is no need for explicit design, removing the barrier to users constructing mashups; mashups also execute automatically without prior configuration (Isaksson and Palmer, 2010).

However, there are also several drawbacks to this approach.

Without explicit “wiring”, widgets are reliant on sending and receiving messages on topics of interest in a format that they are capable of understanding. Isaksson and Palmer (2010) have proposed an approach using a resource-oriented approach, and by including metadata along with the message to aid widgets in interpreting messages they receive. Wilson, Daniel, Jugel and Soi (2011) proposed the development of a limited reference ontology for the widgets within a particular domain of use, for example to support interoperability in enough common scenarios to satisfy most users, but requiring additional work for less common communication tasks.

Another weakness is that with no predefined “plan” of the mashup, there could be the risk of the emergent behaviour of the widgets being pathological – for example, self-reinforcing loops or hunting. This could be a serious problem where the mashup components have real-world consequences, such as SMS-sending widgets.

User Control versus Ease of Configuration

For inter-widget communication, we can identify a number of parameters for the design space independent;y of the messaging infrastructure used to transport them.

In the previous section we discussed one parameter, orchestration versus choreography. Another set of concerns are user control and ease of configuration; in order for users to feel in control of the mashup and its behaviour there is usually a tradeoff with the level of configuration necessary for the environment (see Table 1).

In orchestrated UI mashups, users are directly involved in configuring the interactions between the widgets. While this sets up a challenge for the platform design in reducing the learning curve for the user, it does offer a fairly high degree of user control over the behaviour of the mashup.

In choreographed UI mashups, there is no configuration necessary, however the control is shared between the user in their choice of widgets, and the designers of the widgets themselves, and the interactions are emergent based on those choices. This means that in practice a choreographed UI mashup may create a situation where the user feels the environment is out of their control as widgets interact with one another, possibly even preventing user interaction.

Table 1: Tradeoffs between ease of configuration and user control

	Ease of configuration: High	Ease of configuration: Low
User control: High		Orchestrated UI mashup
User control: Low	Choreographed UI mashups

To progress the state-of-the-art in user interface mashups therefore requires innovation to either reduce the difficulty of configuration in orchestrated mashups, or to improve the level of user control in choreographed mashups.

Improving the usability of orchestrated UI mashups

In the MATURE project, an alternative form of orchestration was used, where the user controlled interactions are managed by proximity in layout. So, for example, to initiate a communication channel between two widgets, the user moves one of them in the layout until it lays adjacent to the other (see Nelkner, 2009). This also enables multiple widgets to communicate. This is an interesting user experience approach, though it isn’t clear how accessible such a solution might be.

In the PALETTE project (See Sire, Paquier, Vagner and Bogaerts, 2009), the platform supported an early form of drag-and-drop interoperability between widgets.

Users could drag elements from one widget onto another, triggering a one-time transmission of data from one widget to another. This work has to some extent been superceded by HTML 5’s drag and drop functionality, however it remains an interesting approach as it demonstrates a case of limited orchestration that builds upon an existing metaphor that is likely to be familiar to users. However, as with drag and drop in the browser generally, there is as yet little user experience or design consistency for drag and drop interfaces, and it can be a challenge providing accessible alternatives.

Each of these prototypes provide an interesting approach to reducing the technical barrier to users in creating explicit channels for the orchestration logic; however in each case they also expose additional challenges for making such solutions accessible.

Improving user control for choreographed UI mashups

We refer to a situation where a set of approaches is taken to constrain a choreographed UI mashup as a hybrid UI mashup.

Perhaps the crudest level of user control that can be added to choreographed mashups is a high level “pause” control so that the user can stop and resume all interactions within a workspace. This would directly control the messaging mechanism (for example, the publish-subscribe hub). Control could also be offered at an individual level, for example to isolate a widget from other widgets in the mashup.

However, each of these mechanisms presents a solution to the “runaway mashup” problem but does not address the general issue of user control in how widgets are supposed to interact before there is a problem.

One approach would be to request explicit user permission before each new interaction; for example, a message such as that in Figure 1 might be raised by a mashup platform the first time that two widgets attempt to share information.

Figure shows Alert box with message: ‘“Map” would like to share “location” with “Flickr”. What would you like to do?”’ with two buttons labeled Allow and Don’t Allow, and a checkbox labelled “Remember this decision.

Fig. 1. Example of a message allowing users to control emergent mashup behaviour.

While this might seem intrusive, enabling this level of user control may be sufficient to shift the balance of user trust for such a system, and could be made less annoying by remembering decisions by users so that they are not asked for subsequent sessions.

Conclusion

There are sufficient projects requiring inter-widget communications in mashups that a need is emerging emerging for a standardized solution, or at least a set of design patterns.

In this paper we looked at two classes of inter-widget communication architecture – orchestration versus choreography – and the design challenges that need to be addressed to overcome their limitations in terms of either ease of configuration or user control.

In the case of orchestration, there have been innovative attempts to reduce the difficulty of configuration for users using different configuration metaphors. In the case of choreography we have suggested several strategies for putting the user back in control of their workspace, however these have not been implemented in a running prototype.

In neither case do we yet have a body of evidence for the usability of these approaches, despite considerable investment in implementations. Al Sarraj and De Troyer (2010) note in reference to visual wiring tools for mashups generally that “These tools target Web users without programming background and promise that creating a Web mashup is just a matter of a few mouse clicks. However, no profound usability evaluations have been performed to justify those claims.” While there has been investment in researching ways to simplify mashup enabling tools for end-users, this seems to be largely on the basis of intuition rather than an understanding of user needs or competence, and in some cases focus on metaphors understood by engineers (e.g. wiring diagrams).

Other researchers have also reported accessibility issues with mashup platforms (Schwerdtfeger and Parente, 2008) that need to be addressed. For example, where changes propagated across widgets take place without notifying the user, potentially also disrupting keyboard navigation or window focus.

Therefore we recommend that, before committing to standardizing approaches to inter-widget communication from an engineering perspective, there should be corresponding work in the usability of user-created mashups taking account of users perceptions of the issues of configuration complexity and degree of user control, and to identify the set of design metaphors and language for mashups that a broad set of users can relate to.

References

Sire, S., Paquier, M.,Vagner, A., and Bogaerts, J.: A Messaging API for Inter-Widgets Communication. Proceedings of the 18th international conference on World Wide Web, 2009. ACM New York, NY, USA. ISBN: 978-1-60558-487-4

Wilson, S., Daniel, F., Jugel, U., and Soi, S.: Orchestrated User Interface Mashups Using W3C Widgets. Proceedings of 3rd International Workshop on Lightweight Integration on the Web (ComposableWeb 2011), Paphos, Cyprus, 20th June, 2011. Springer.

Law, E.L.-C, Muller, D., Nguyen-Ngoc, A.V.: Differentiating and Defining Portlets and Widgets: A survey approach. 2nd Workshop on Mash-Up Personal Learning Environments (MUPPLE-09), Nice, France, September 29, 2009.

Isaksson, E., Palmér, M.:Usability and Inter-widget Communication in PLE. In Proceedings of the 3rd Workshop on Mashup Personal Learning Environments (MUPPLE10), Barcelona, Spain, September 29, 2010, CEUR Workshop Proceedings Vol. 638, 2010.

Nelkner, T.: An Infrastructure for Intercommunication between Widgets in Personal Learning Environments. In WSKS (2)(2009) 41-48

Lizcano, D., Soriano, J., Reyes, M. and Hierro, J.: EzWeb/FAST: reporting on a successful mashup-based solution for developing and deploying composite applications in the upcoming web of services. In Proceedings of the 10th International Conference on Information Integration and Web-based Applications & Services (iiWAS ’08), Gabriele Kotsis, David Taniar, Eric Pardede, and Ismail Khalil (Eds.). ACM, New York, NY, USA, (2008).15-24.

Hoyer, V., Gilles, JT, Stanoevska-Slabeva, K.:SAP Research Rooftop Marketplace: Putting a face on service-oriented architectures. IEEE Congress on Services, pages 107–114, 2009.

Villar, N., Lindsay, A., and Gellersen, H. Pin & Play & Perform: a rearrangeable interface for musical composition and performance. In Proceedings of the 2005 conference on New interfaces for musical expression (NIME ’05). National University of Singapore, Singapore, Singapore, 188-191.

Zuzak, I., Krolo, J., Srblijic, S. Geppeto: Promoting End-users to Gadget Developers. Google Tech Talk, Mountain View, California, USA (2008). Talk: accessed 4th July 2011 from http://www.youtube.com/watch?v=fbUvCdADz_A

Ivankovic, M. and Zuzak, I. List of system that enable inter-window or web worker communication. Website, April 2011: http://code.google.com/p/pmrpc/wiki/IWCProjects. Al Sarraj, W. and De Troyer, O. Web mashup makers for casual users: a user experiment. In

Proceedings of the 12th International Conference on Information Integration and Web-based Applications & Services (2010). ACM, New Y ork, NY , USA, 239-246. DOI=10.1145/1967486.1967526 http://doi.acm.org/10.1145/1967486.1967526

Schwerdtfeger. R., and Parente, P. Web 2.0 mashup accessibility. Website, 2008: http://www- 03.ibm.com/able/resources/mashup.html

Edukapp – a white-label open-source web app store

Recently I’ve been working with Lucas and Fridolin at the Open University who are leading on a project called EDUKAPP, which is a pilot for a web app store for the UK Higher Education sector. The idea is to provide a place to find and share widgets (including both W3C Widgets and OpenSocial applications) for the UK HE community.

Rather than just build a single store, however, we’ve been working on a generic codebase that can be customised for other sectors and communities. We’ll be using this in the ITEC project for its widget store, for example, which is aimed at secondary schools across the EU.

The basic architecture of the EDUKAPP code is a combination of Apache Wookie, Apache Shindig, Apache Solr and Apache Shiro. The actual store is a backend service primarily accessed using JSON APIs to make it easier to create your own UI – there is a default UI that uses Twitter Bootstrap, which should also be fairly easy to customise.

Last week at the JISC CETIS conference we had a chance to meet with potential users and integrators to get some feedback on early prototypes, and we had some great suggestions.

First off the approach of keeping the services and UI separate was seen as important, as not only are we looking at having a few large-scale services running based on EDUKAPP, but also individual sites such as Universities want the ability to deploy store access via plugins in their existing systems – for example, a simplified interface that can fit into a sidebar or block in a learning management system.

For embedding and integration, we need to support lots of different options. For integration with learning management systems we’re implementing IMS LTI. However, we also have to support simple embedding via JavaScript embed code, downloading as .wgt packages, possibly also incorporating hybrid mobile app support using Apache Cordova (the code behind PhoneGap), which can transform W3C Widgets into iOS, Android and other native packaging formats.

A very interesting idea that came up from the meeting was the ability to fork widgets, Github-style. The idea would be that if a university came up with a great widget, for example a timetable app, they could publish this in the store, and developers or students at different organisations could create a fork of it and modify it to work with their services.

We also had chance to talk to folks from IMS who are working on a new version of their LTI spec to specifically handle simplified integration of widgets into learning management systems without having to copy-and-paste URLs and keys, which would be a great usability improvement.

If you’re interested in EDUKAPP, the project is not only open source but also very much open to anyone else getting involved – the project is itself based on a multi-project collaboration already. Its also still at an early stage so there are plenty of opportunities to shape the project direction. There is a Google Code project and also a mailing list. (So far the list has been mostly used by me for posting code updates, but please feel free to ask questions or suggest ideas!)

Enyo: a component-oriented JS framework

Enyo first made an appearance on the HP TouchPad and was the framework used for WebOS applications.  However, after HP killed the TouchPad and put WebOS development on hold, HP has spun off Enyo into a standalone open-source JS app framework on Github.

The framework is being billed as device agnostic, that is web applications built with Enyo should work great on mobile, but also will live happily on tablets, laptops, and elsewhere. This is a good position to take, as increasingly web application developers are having to consider a wide range of target devices rather than just focussing on mobile and/or desktop browsers. For installed mobile apps, the project recommends using PhoneGap to package Enyo applications with native wrappers.

Another key feature is a component-oriented model, where you can take parts of your site and encapsulate them as reusable components – for example a common form layout or a common control type. This looks like an interesting way to create DRY web applications at the client side.

Enyo is still at quite an early stage of release, and most critically is missing the UI Widget components. Until these ship (according to the FAQ they should be out next month) there isn’t a great deal of point using Enyo unless the idea of component-oriented design is something you’re really into. However, looking forwards it could be an interesting competitor to frameworks like JQueryUI and JQuery Mobile.

I don’t know to what extent the original HP team are still involved in Enyo, but the project seems to be attracting attention on Github and a community is forming around it. It would be good to see some part of the WebOS dream live on.

For more information, check out the Enyo site.

Revolutionary messaging technology will challenge FB, Twitter, IM

I’ve been having a go recently with a really cool communication technology – just check out some of these features:

• It works on all kinds of devices and across all networks
• You can search, read and respond to messages even when you’re offline
• Works with intelligent filtering services
• You can send and receive messages with anyone on any network, not just the same service provider you use
• The server code is open source so you can run your own
• Completely distributed architecture with no central server or hub node
• Uses open standards for pretty much everything
• Clients for all platforms including mobile, even TV – and anyone can make their own client as the API isn’t proprietary
• You can send messages of any length, including rich text, images, links and documents
• You can create “lists” of people to message together as a group, again even if they don’t use the same server or service provider as you
• You can embed links in your web pages that automatically launch the user’s client with a new message to you (a bit like Web Intents)
• You can publish archives of messages on your own website
• You can save your messages on your own computer, back them up on a usb stick, or store them in the cloud – its up to you
• It doesn’t matter if the company that invented it goes bust or gets bored with it and stops developing it, as there are lots of alternatives and pretty much every tech company is backing it.

I think this is a really cool technology, and I encourage you to take a look at it. Find out more here!

However, not everyone is convinced yet and think that we should stick with proprietary messaging silos tied to one service provider such as Facebook and Twitter, despite the obvious risk of these services being discontinued, monetized, tracking your communications for nefarious purposes, and spamming you with advertising at any opportunity.

 

Creating “Write That Thesis!” at the ROLE developer camp

Last week I attended the ROLE Developer Camp in Leuven, Belgium in my role as a “developer advocate” for the project. ROLE has been developing lots of interesting technologies around flexible personal learning environments, and this event was partly to showcase some of those developments, and partly an opportunity to build some widgets with the prospect of prizes for the best entry!

I mentioned ROLE in a previous post, where I encouraged them to work with the Apache Rave project and its great to see this suggestion being taken up seriously by the project team; hopefully we’ll start to see contributions from ROLE to Apache Rave soon. Rave is a “white label” social network/portal platform that includes support for both OpenSocial and W3C Widgets (using Apache Wookie) and at the event Jasha from Hippo and I were each able to show W3C Widgets and OpenSocial gadgets being combined in workspaces which was a great demo.

For the actual widget competition, I worked with Li Na, Sten Govaerts and Felix Mödritscher on a fairly simple widget that tracks how well you’re progressing towards getting your first draft of your thesis written. While this sounds quite trivial, I think its best to work on quite basic problems and expand out (something I elaborated on in a talk at the barcamp). So we created a HTML5 app using Local Storage rather than any advanced APIs, and then created the W3C Widget package and an OpenSocial gadget.xml afterwards, lastly using PhoneGap to create some native mobile versions.

We also developed it using Dropbox as our collaborative IDE! This wasn’t completely ideal compared with SVN or Git but did mean we could all work simultaneously on the widget, although it worked best if we were hacking different files rather than all editing the same script, as it resulted in lots of conflicts. However as a quick “get it done” environment I think it worked pretty well, and we were very productive.  I’m sure this contributed to our winning First Prize (though I think the fact our widget is bright pink didn’t hurt either).

Try it out yourself at http://labs.cetis.ac.uk/thesis or get the code from github.

For more information on ROLE, see the project website.

 

Web Intents

Most web developers are familiar with handling integration with other applications using APIs and messaging protocols, but we could be in for a major shift in how we connect applications with the emergence of web intents. Some demos were released earlier this year to explain the concept, which is now undergoing development in W3C for a new web standard.

Briefly, the web intent approach relies on the browser acting as a broker between websites. Each website can offer to register itself to provide a particular service for the user, such as sharing photographs. When another website wants to allow users to make use of such a service, it creates an “intent” containing the type of service to be used, and the payload data. The browser can then offer the user with a choice of which service to use.

For example, if you use Flickr and Picasa, you might allow your browser to register these sites to provide the “share image” service. If you use a drawing widget, it could then have a “save” button that uses an intent. When you click “save”, you would be offered the choice of using Flickr or Picasa for saving and sharing the image you created.

The same approach can be used to share links and clippings as well as media.

The benefits range from minor things such as reducing the clutter of “share” buttons on sites, to potentially opening up services much more widely as developers no longer need to implement integration points for services directly. This means that rather than defaulting to a few widely-adopted services, niche service providers could also fit into the ecosystem alongside the well-known brands. In higher education, for example, specialised image collection and research link management tools could have the same effective level of integration as Flickr and Digg; likewise academically-oriented reputation and recommendation services could have as ubiquitous access as the Facebook “Like” and Google “+1″ services.

Currently, you can only use Web Intents via a JavaScript shim which can be used to create demos. However, its likely the technology will be standardised in W3C and added to browsers in the near future.

Digital wallets and mobile payments

I’m now spending part of my time working on the JISC Observatory, so I’ll be writing occasional tech trends posts here. 

While it could be argued that for most people money went virtual a long time ago with the emergence of online banking and debit cards, there is a strong trend towards “appifying” payments with digital wallets and mobile payment mechanisms.

Square[1] and Google Wallet[2] are the ones making the headlines, but others may be close behind.

In universities, contact-based payments are already used in cafes and libraries using cards such as Squid[3]. Contactless payments are also making their way onto the high street [4][5].

In a slightly more bizarre move, MasterCard is adding contactless payment technology to wristwatches [6].

Most of these systems use variations on RFID and NFC technologies, however perhaps the most critical component is the software, and the service infrastructure that lies behind it[7].

For education, this may not seem like a particularly important development, however most universities and colleges need to handle payments across a wide range of services and facilities (cafes, library, short courses, shop, events) and will probably need to start planning for accepting contactless payments across campus.

[1] Square’s updated Card Case app gets you a step closer to ditching your wallet
[2] Google Wallet is hitting the road for a 5-city tour with $10 “bribes”
[3] http://www.squidcard.com/
[4] Contactless ‘pay at the tills with a mobile’ system introduced 
[5] Firms hope London Olympics push contactless payment across Europe
[6] MasterCard Rolls Out Prepaid Contactless Wristwatch in U.K.
[7] Swift mobile wallet adoption hinges on apps 

Five Signals

I’m now spending part of my time working on the JISC Observatory, so I’ll be writing occasional tech trends posts here. 

Mobile

Every vision of the future now has a strong place for mobile [1][2]. We’re seeing consistent trends for increasing data use and service access from mobile, and ubiquity of devices, and a strong rise in smartphones as a % of total device ownership. The form factor for smartphones has been established as pure touchscreen interface, with a fairly stable set of standard sensors (GPS, accelerometer, compass, microphone, camera). Innovation is mostly focussed on incremental improvements in each of these aspect [3]; however a recent game-changer is the Siri voice recognition interface [4][5], particularly for blind users, but also as an advance in interaction methods more generally.

Analytics

Analytics and “big data” are terms being applied to all kinds of sectors and topics, including learning, health, management etc. Mobile analytics [6] is an emerging area, where organisations try to take advantage of the contextual data possible with mobile platforms. In education, areas where analytics are being applied include tracking learner attention [7], behaviour management [8], truancy [9], teacher performance evaluation [10] and school dashboards [11].

Tablets

The tablet computing category now appears stable, and has effectively killed off netbooks. From the top end iPad, to the $35 device from India [12] [13], there is now a wide range of devices spanning 7″ to 11″ screen form factors. Attention is being placed, as might be expected, on educational applications [14], and in particular to the area of textbooks (see below). A future vision from Microsoft [1] also puts an emphasis on tablets, with possible new future forms including foldable tablets, tablets that can link together into larger canvasses, and surface-based computing.

 Apps, Widgets and Appification

“There’s an app for that” has entered popular culture; almost any service can now be envisioned as an app, from healthcare [15] to agriculture [16]. The key challenges are device and OS fragmentation keeping costs high relative to returns for new entrants, also a worry for education as “bring your own device” can mean “bring your own interoperability problem” [17]. However services like PhoneGap (acquired this month by Adobe [18]) based on HTML5 and W3C Widgets are emerging as the way to solve this in the short term. W3C gained very significant interest in the are of “offline web applications” from a wide range of vendors, suggesting the area of partially-disconnected applications could be one to watch [19].

e-Textbooks

The “textbook problem” seems to have rising prominence in education technology policy. In Asia, there is a strong push for e-books, e.g. in China from a slow start last year [20] huge growth is now likely [21]; in South Korea [22] there is also a major national strategy. In the US, the concept is even making front-page news [23] although the focus is more often on the hardware – especially iPads [14], although the Kindle Fire platform seems to be garnering attention too [24]. Even Steve Jobs’ posthumous biography states it was his intention to disrupt the textbook market [25]. Again we have an issue of standards and interoperability, particularly as we move beyond basic PDF and e-Book formats towards e-textbooks providing advanced  capabilities such as built-in testing and feedback functions.

REFERENCES

[1] http://venturebeat.com/2011/10/27/microsofts-vision-of-the-mobile-future-is-astounding-video/

[2] http://venturebeat.com/2011/10/27/rim-mobile-future-video/

[3] http://www.tmdisplay.com/english/news/2011/2011_1020.htm

[4] http://www.apple.com/iphone/features/siri.html

[5] http://mashable.com/2011/10/03/iphone-5-assistant/?utm_source=twitterfeed&utm_medium=twitter

[6] http://radar.oreilly.com/2011/10/mobile-analytics-unlock-the-wh.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+oreilly%2Fradar%2Fatom+%28O%27Reilly+Radar%29

[7] http://www.downes.ca/cgi-bin/page.cgi?post=56221

[8] http://www.classdojo.com/

[9] http://www.bloomberg.com/news/2011-09-30/robo-truant-tech-and-other-apps-to-fix-education-jonathan-alter.html

[10] http://formativelearning.com/

[11] http://eduvant.com/

[12] http://mindshift.kqed.org/2011/10/can-a-35-tablet-be-as-effective-a-learning-tool-as-an-ipad/

[13] http://liliputing.com/2011/10/aakash-android-tablet-hits-india-for-60-or-less.html

[14] http://finance.yahoo.com/news/Many-US-schools-adding-iPads-apf-1245885050.html?x=0&.v=2

[15] http://www.businessweek.com/magazine/mobile-health-apps-arrive-09292011.html

[16] http://venturebeat.com/2011/10/27/farmers-turn-grass-into-cash-with-the-grassometer/

[17] http://mfeldstein.com/does-byod-solve-or-worsen-k-12-tech-woes/

[18] http://news.cnet.com/8301-30685_3-20114857-264/adobe-buys-phonegap-typekit-for-better-web-tools/

[19] http://www.w3.org/2011/web-apps-ws/Papers

[20] http://www.chinadaily.com.cn/usa/2010-08/02/content_11080657.htm

[21] http://economictimes.indiatimes.com/tech/internet/china-sees-e-book-boom-prefers-e-books-rather-than-paper-books-survey/articleshow/8054153.cms

[22] http://www.csmonitor.com/Books/chapter-and-verse/2011/0706/In-South-Korea-all-textbooks-will-be-e-books-by-2015

[23] http://www.nytimes.com/2011/10/19/education/19textbooks.html?hp

[24] http://blogs.hbr.org/cs/2011/09/amazon_kindle_fire_scare_apple.html

[25] http://chronicle.com/blogs/wiredcampus/steve-jobs-had-hopes-of-disrupting-textbook-market/33912