Writely, Google and Open Office

The acquisition of Writely by Google is covered in depth in many place including the implications for Microsoft. Is Web 2.0 for the institution really coming? This acquisition would suggest maybe. One interesting point that I picked out of a talkback on zdnet was the cross format capabilities of Writely. You can open HTML, Word, RTF and Open Office format files and Save As the same formats and, for a price, PDF .

The way Writely joins together many of the core ideals of Web 2.0 including the Web as the platform, the architecture of participation and the way Writely provides the practical ability to seamlessly move documents between aplications and document formats can be seen as a powerful model for the future.

WSRP

Prompted by conversations in the last week with Ian Dolphin and presentations at a recent workshop on portlets and VREs has led to some concerns about the future of WSRP.

Matthew Dovey gave a thorough overview of WSRP and the ongoing work of the specifications team looking at version 2.0.
Concern 1 - Matthew said that none of the vendors involved with WSRP 2.0 are working on an implementation of the new version.

This was followed by the work of Xiaobo Yang at CCLRC Daresbury who investigated the compatability of WSRP producers and consumers.
Concern 2 - in the majority of cases, sometimes even using the same portal framework, the producer and consumer failed to communicate correctly with each other.

This also highlights the problems of Concern 3 - if there is this incompatibility across portal frameworks how will it be possible to support WSRP longer term, a concern raised by a colleague at the JISC data service EDINA. The coding of the producer for a central service is a known, but unknown is how the consumer in different portals will communicate with this producer.

Which brings me round to my suggested solution to some of the problem. Given the wave of Ajax and other clever client-side technologies being used currently, surely we could have a WSRP lite consumer that could be embedded in a plain HTML page. Not only would this remove the support headache, you only support the consumer you have written, or test with a de facto widely used consumer, you also instantly, and significantly, increase the availability of your WSRP fronted service to a much larger audience, those who don't have a portal. This has been discussed on the WSRP list but according to this message it looks like it will be a while before anything is taken further.

I started this feeling slightly negative about WSRP, and there are huge issues, but it would appear that there are opportunities to move forward. Finally, its interesting to note that a quite large software company in Redmond are looking to introduce a WSRP consumer to Office 12. I'm not sure of the use cases but it does raise new possibilities around the convergence of desktop apps, the browser and the portal.

... ask what portals can do for Web 2.0

Over the last couple of weeks I was putting together a presentation for a workshop on Divergent Technologies. This raised some interesting questions around the use of Web 2.0 technologies, the deployment of a service oriented architecture and the differences the adoption of SOA makes. This is especially evident when looking at the portal diagrams, the move to SOA will introduce a significant level of abstraction.

The point of this post, particularly as a follow on to the Future of Web Apps thoughts, is having considered what the Web 2.0 approach could do for re-thinking portal architectures, what can the portal do for Web 2.0. This may also take us further along with thoughts as to what the next generation portals could and should be like. The Web 2.0 and portals slide from the presentation highlight a number of features where a portal can directly support Web 2.0 or is already attempting to achieve the same, or similar, things. These features are taken from the original O'Reilly paper on Web 2.0.

The first two, Web as the platform and you control your own data, are key drivers for the development of institutional portals. We want individuals, whether staff or students, to be given the opportunity to self-provision, maintaining their own data, using the common platform of the Web and spanning any browser/operating system combination (within reason). This can also be extended as better more flexible service based systems are developed to allow individuals, groups, and more formal organisational units to, for example, store and share information, using the portal as both an interface for storage and a means of dissemination amongst those interested in or allowed to view the information.

I think this also seeps into the concept of an 'architecture of participation', allowing users, as they require or would like, to participate in any number of online communities, bringing together those with a similar interest as well as providing collaborative spaces for those who already knew they had a shared interest.

Cost effective scalability has in the past and continues to be proven by the large number of people using open source software for running portals. We have used uPortal for sometime and have found it to provide the degree of flexibility and stability required to run live services for a significant number of users.

The final point, services not packages, is reflected across all the IT sector in the previously mentioned service oriented architectures which I'll come back to at a later date. Having had an epiphany some years ago around Web Services and the potential of SOA, I feel there is now real momentum behind the ideas that will result in 'real apps' for our users.

MINTED

Interesting project from Sussex, MINTED, part of the latest JISC ELF toolkits. Looking to use IMS standards to integrate Moodle with their home-grown student records system. There are working with the CETIS Enterprise toolkit and also looking at use of IMS enrollment module.

This is directly addressing an area of work we need to complete with Sakai over the next six months: automatic creation of users, courses, and subsequent enrollment on the courses. The use of the standards is very attractive, particularly in this ever moving space. Theoretically, all we need to do is create a new JDBC adapter for our HR and SRS and look at adaptation of Sakai WS to perform the IMS enrollment. We may actually work this inside out, start with basic Sakai operations and abstract it out to meet the IMS standard.

Web 2.0 lessons for portals?

At the Carson Workshop an the Future of Web Apps. Unfortunately due to trains I missed most of the first talk from del.icio.us. The following talks from Cal Henderson at flickr and Tom Coates of Yahoo (isn't that the same company?) were excellent. Two common Web 2.0 themes emerged from these presentations for consideration for implementation in next generation portal frameworks.

The first is the expectation that any system will have a full set of Web Services based APIs, the foundations for the realisation of the Web 2.0 goal to use the Web as the platform. Longer term one can start to imagine, not a monolithic piece of portal software, but actually a loosely coupled collection of services with a default interface. At this point, people can create any number of 'portals', based on their whims and requirements, with any number of new user experiences being made possible. Also, the portal stops being tied to the browser, desktop apps can start to utilise the portal APIs. These include existing aggregation tools either through the browser, such as Google ig, or on the desktop, Google desktop. You can see a time not too far in the distance, via the Google desktop API where access to institutional information and apps could all be securely facilitated to the desktop, potentially even removing the need for a browser. This is obviously in the longer term...

The second issue both raised was the provision of easy access routes to core data held by a service, e.g. photos for Flickr. The access routes are provided by the creation of clean URLs, that is, URLs that are permanent, human readable, reliable and hackable. A URL needs to provide direct access to content and applications without displaying the inner workings of the software. Tom Coates describes good URLs as beautiful and 'just right'.

Web 2.0 is as much about access and reuse of content as it is about the integration of APIs. In the future the portal could also act as a broker of content and applications enabling the reuse of portal aggregated content outside the portal, preferably made available via clean URLs. Either in combination with the disaggregated portal functionality already described or as a stand alone, this further increases the potential uses of the portal.