stressfree - tagging

Folksonomy talk

David — Thu, 12 Oct 2006 23:35:36 +0000

Over the last few weeks I have been concentrating on more formal writing hence the limited number of blog entries. Once this formal writing reaches a point where I feel comfortable with the structure and content I will most probably publish it up here, until then hold tight. In the meantime I have come across a couple of very interesting links related to tagging and folksonomies that are worth remembering.

Folksonomy Generation

David Weinberger has a very interesting post and comment thread named 'What is a folksonomy anyway?' where he tries to come to terms with exactly what a folksonomy is and how it comes about. It is commonly agreed that a folksonomy is a set of user generated tags assigned to related pieces of content, but the real question is what role does the process of tag creation have to play in the establishment of a true folksonomy?

"In fact (I'd thought), if you really want a folksonomy to develop, you give people some feedback about how others are tagging the same or similar objects."
_{David Weinberger}

By simply providing a mechanism for 'free tagging' of content does that generate a true folksonomy? Without feedback from other like minded users what typically results is independent sets of user generated tags that have marginal relationships with each other. When users are given feedback during the tagging process about how similar, hopefully like minded-people have tagged content then the tagging process gains more significance. Not only are common tags reinforced but individual or situation specific tags can be derived as well. From the looks of the comments opinion seems divided on this topic and there are good arguments backing up both sides.

From experience and the perspective of using folksonomies to aid in group work it is my opinion that providing feedback during the tagging process is a crucial element to a folksonomies success. In the Reasonate testing before team tagging feedback was provided tag use was limited by students and when applied was so distributed and unique that no useful relationships, search indexes or higher operating structure could be reasonably derived. Once tag feedback was applied in the form of either team or class level tag clouds students began to apply tags more consistently and frequently. In hindsight this feedback process would seem to fit human nature as it acted as an incentive. Group level suggestions also form a very useful starting point to any tag thought process, much like beginning to paint on a blank canvas can be daunting but by laying down a few initial strokes it gets the mind working and the paint flowing.

Tagging and its limitations

Tagging and folksonomies are not the solution to all of life's data problems as Abby from LibraryThing describes in her post entitled 'Tagging Meets Subject Headings'. Within the post she highlights the benefits of tagging such as its ability to capture data not directory associated with existing meta-data. She then goes on to explain where tagging is not so successful such as in cases where a piece of data is either one thing or another (true or false). Tagging is not good with binary decisions like this as it is indicative of a single opinion. Consequently the general perception is that associated tags indicate content is 'kind-of this' or 'mostly that' but not unquestionably one thing. Her advice like most things in this world is to apply tagging in moderation and when it is not the most appropriate source of meta-data always be prepared to seek other sources of data.

Visualisation of folksonomy relationships

A while back TechCrunch reviewed WizTag, a newish online RSS reader service. What got my attention was WizTag's TopicMap visualisation functionality which is similar in effect to Google Maps but for tag clouds. WizTag generates mind map diagrams of tag clouds complete with lines representing relationships that are scaled depending on the quantity and frequency of user submissions.

There is a little zoom feature that allows you to control the size of the diagram Google Maps style. Unfortunately I was disappointed with this feature mainly because it reminded me so much of Google Maps that on zooming in I half expected more data to be exposed but instead you just get a larger image of what is already onscreen. What I really wanted to see happen as I zoomed in was the individual tag topics get broken down into their component parts and relationships so that I could get a better idea of the specifics that made up a particular tag cloud. Not only would this have looked really cool but it would added an extra degree of understanding to the diagram that at the moment is a little boring once you get over the initial image. Still as you can the overall idea is quite effective in identifying areas of current interest and the strength by which different concepts are related to each other.

Small featurette inspiration from Dave Weinberger

David — Thu, 18 May 2006 09:45:14 +0000

I was reading David Weinberger's blog today and saw two interesting things, the first was a dilemma he was facing with tag namespaces and the second was his idea of an 'ideal tag results page'. The first discussion centered around which website should be referenced when blog tagging (i.e using the rel="tag" microformat). A general theme in the subsequent comments was that his tags should first link back to his own blog site to show his tagged blogs and then from there provide links to other tag services (like Technorati, del.icio.us or Flickr).

I liked David's concept for his ideal tag results page where links to Flickr, del.icio.us and Technorati search results pages were easily accessible. The idea was so easy to implement I straight away put the conept to work within Reasonate. I added the links to these external sources just below any related tags on the search results page. Whilst I am not too sure of the usefulness of the Technorati link in the context of Reasonate the del.icio.us and Flickr links are very useful, you'll be surprised at the number of tagged bookmarks and photos out there.

The new Reasonate tag results with external tag service links (click to enlarge)

Of course the search is a little limited because unlike the two of the three forementioned sites (Flickr and del.icio.us) Reasonate supports multi-word tags. Consequently doing a search for 'archicad tutorial' does not work because such a term could never exist in these services as currently designed. I had debated with myself whether to allow/not allow multi-word tags. I eventually went with multi-word tags simply because in the design/construction industry there are many terms that really only make complete sense when considered as a single entity (such as pitched roof or gothic entrance). But in saying this the argument could equally stand that single words work better as there would be fewer, more concentrated tags which would lead to richer tag clouds. This will need more thought...

On Wrap-ups

David — Mon, 15 May 2006 10:04:09 +0000

A Mash-up in the Web sense is when you grab a bunch of disparate API’s, say Google Maps and live crime statistics and come out with something whose sum is greater than that of its parts (in this example chicagocrime.org). A Wrap-up is my term for the grouping of hyperlinks and tags with a supporting wiki-based summary of the ideas, issues and decisions reached within the identified dataset. In both cases the outcome is of more inherit value than its component pieces. Yet without the individual value of the compontents the end result lacks credibility or interactivity, making the concept as a whole less appealing or conclusive.

As I said in my last post a major issue we were facing in the Reasonate testing was quickly gaining an global overview of a project or individual’s progress without having to read and understand numerous scrapbook-like blog postings. Just to complicate matters these posts are often related to, but not explicit in their overall meaning or relationship to the design’s end goals. Or how I put it more pragmatically last time round:

“What was needed was a mechanism easily ‘wrap things up’ into a format that was easily disseminated by the casual observer yet retained the rich chronological underpinnings the blogging process had successfully established….”

This process of wrapping up tied into something mentioned by both Robert Amor and Mark Burry when I had seen them last (at separate times). Both had mentioned Australian research into the use of Wiki’s in the design process, or more specifically the work of Jane Burry on wiki.

My initial reaction to wiki is negative. This is in part because I’ve seen a number of software projects try to solve their problems by creating a wiki only at the end of the process to have a very expansive website filled with lots of very empty pages. Also I feel by their very nature wiki are viewed as authoritative sources of information rather than places for conversation or debate. Probably the best argument I have for this is that the most successful wiki are authoritative in purpose, such as Wikipedia and community-orientated software documentation like those in place for Ruby on Rails or the Hula Project. In most situations the edits made are not viewed as some form of ongoing debate but rather a case of who can get the last word in on a subject matter usually very close to the author’s heart. There are many examples of this on Wikipedia such as Adam Curry’s revisionist edits on Podcasting and perhaps more worryingly attempts by employees within the U.S. Congress to publicly pimp their politicians.

Attitudes like this don’t bode well to wiki use within the initial phase of conceptual design which is why I have focused more energies on the use of blogging in this area. However as has been found with Reasonate testing, too much stream of thought and scrapbooking of ideas and not enough authoritative opinion can be just as bad as single, dominant personality commandeering a wiki for use as a personal soap box.

Enter the Wrap-up.

One of the most useful things I find about Wikipedia entries is not the text itself but the external references usually listed at the bottom of the page. These references act as reassurance and further reference for the subject matter detailed in the wiki document. The Wrap-up would be the intelligent collection of aggregated project blogs, files and tags provided through the Reasonate API for summarising (wrapping up) in a wiki environment.

Over the last few weeks my attitude towards what Reasonate programatically has changed after a very fruitful meeting with Mike where we discussed Web 2.0 services and how they related to Reasonate. The logic behind this thinking will appear in my next post but to summarise I see Reasonate now as a 'Building Information Aggregation Service' (BIAS). Rather than a standalone user experience Reasonate should be a service that pulls together various project information sources and then projects this information against a defined participant/project structure. The outcome of this process would be an intelligently searchable index interfaced primary via a Google-like API, or for a more simple explanation, think Technorati for design projects.

With this intelligent index you can then construct search terms that form the basis of the project wrap-ups. You could for arguments sake construct wrap-ups out of an explicitly defined set of URL’s but this is ineffective. For one URL’s in the real world are not constant, domain names change, software behind blogs is updated breaking older URLs and content is deleted or edited to the point where it no longer bears any resemblance to its former self. Secondly its difficult to justify something that is arbitrary, a data-set constructed of a specific date-range, tag and author combination by its very definition begins to tell a story, whether it is useful or not comes down to the authors of the wiki wrap-up.

For example a conceptual design wrap-up may specify the following content constraints:

Published between X & Y dates
Submitted under the Project A category
Submitted by members of the design team

This filter would create the backdrop for the wrap-up Wiki entry and through its data-set establish those participants in the project who hold editing rights. The search filter would also be used as the basis for establishing associated resources to the wrap-up Wiki such as links to files, blogs and tag clouds. This would remove a lot of the manual groundwork associated with a wiki and leave the authors free to concentrate on one thing, wrapping up the activities embodied in this aspect of the design process.

Being able to define intelligent search filters would also hold significant productivity improvements when it came to generating the wiki wrap-ups or simply understanding design progress. Rather than having to review the entire process to establish appropriate ‘wrap-up’ moments template rule-sets could be applied based on prior experience. Also perhaps more importantly wrap-ups like the ‘brief’ could be easily reassessed during the design process to see if the underlying conversation has changed significantly enough to justify a reassessment of the ‘brief’ wrap-up. For example, if the wrap-up was written in March how many new posts/tags since then have been introduced to the underlying filtered set and how does this influence the summarised idea?

On a slighty different (but similar) discussion thread

As an endnote something that came to mind as I mentally debated the 'meaningless page full of links scenario' versus a more intelligent search filter based on approach was a recent podcast discussion between Doc Searls and Steve Gillmor. Doc Searls employs a very hyerlink rich blogging style, sometimes to the point that the post itself becomes slightly meaningless (unless reading 'here is good, so to here and here but not this' makes sense to you). Steve's underlying point was that the power of the hyperlink lay not in its end-point but rather its intent and how others have (or have not) found the link as a tool for furthering some intention useful. This concept feeds into his ideas around gestures, especially the Gesture Bank and the AttentionTrust. These movements are something I must admit I struggle to understand but on listening to this podcast I definitely agreed with his opinion that a pool of static hyperlinks without explicit intention hold a lot less value than one may like.

About Reasonate

David — Mon, 15 May 2006 04:00:49 +0000

For the last few months I have been very busy developing and testing Reasonate within the BBSc303 ‘Digital Craft’ class at the VUW School of Architecture. The main purpose of the testing was to evaluate the adoption rate and usage trends of blogging and tagging within a simulated team design process. In concert with this goal the testing was also used to establish what sort of toolset design-orientated bloggers require, especially when operating within a structured environment of project groups, tutors (fellow students) and course coordinators (the lecturer, Mike Donn and myself).

In this test the ‘process’ is the digital modeling of an existing art gallery. The ‘design’ aspects are centred around the decisions the teams must make whilst modelling and rendering this existing building. The types of decisions ranged from the selection process of the gallery, choices on CAD standards and the moves made to overcome modelling/rendering issues during the project. Previous BBSc303 courses have run for the last eight years using a similar format, but rather than using a blogging system the design process documentation occurred at the end of the course and was presented in the form of a static HTML website (usually one or two pages linked together).

The major drawback of the process previously undertaken was the quantity of last minute, post-event justification that took place. Rather than documenting the actual processes as they happened the final submission was usually a last minute exercise outlining how things hypothetically occurred in an ordered fashion (whereas arguably most project decisions where more evolutionary or accidental in nature).

The functional purpose of Reasonate was to get students blogging their activities as they happened. In the course introduction guidelines on exactly how this blogging should be undertaken (in terms of frequency and content) were deliberately left open for interpretation. What was made clear however was that the marking process would only concentrate on Reasonate submitted content so the obligation was on the students to get as much online as they felt comfortable with in order to qualify for marks. In a follow up lecture nine weeks after the beginning of the course further emphasis was placed on the story-telling requirements of the process after observation that many blogs had a very strong scrapbook feel to them.

Functionality

Reasonate was developed as a web application and made available for student use within and outside of the University at http://www.reasonate.co.nz. For the testing process Reasonate had to support the following functionality in order to satisfy course requirements:

Identity of students and flexible project groups

Arguably the most important feature of the system was the ability to create student identities that could then be associated into project teams. Creation and basic management of project teams were left up to students to perform whilst the administrator (Mike Donn) held final sway as to whether the proposed project and student combination was accepted or not. The project construct aggregated the blogs of the participating students. This aggregation generated project blogs that were the sum of all the student blogs associated to a particular subject. This aggreated blog system is very similar to the philosophy behind the Planet project.

The aggregated project blog (click to enlarge)

Blog posts

The primary form of data entry was through blog posts. The interface provided a Javascript based WYSIWYG HTML editor (TinyMCE). The HTML editor provided the ability for students to set font and colour characteristics and easily insert tables, hyperlinks, tables and lists. One feature not included was a spelling checker as at the time this was seen as superfluous to requirements. In practice however a spelling checker probably would have been appropriate given the often poor quality of grammar employed by students.

The new post interface of Reasonate (click to enlarge)

Uploading of files to posts

Digital design is a file-based process so the simple uploading of files was viewed as necessity. The upload process utilised the email philosophy of ‘attachments’ rather than embedding file links directly within the HTML posts. When students uploaded a file a basic form of versioning was employed, the file was saved on the server with a datestamp preceding the real filename. This allowed multiple versions of the same file to be uploaded without naming conflicts occuring. Within the Reasonate database a file entry was created that linked the datestamped file with the original filename. Project files of the same name were considered to be different versions of the same file and within the Reasonate interface it was possible to view and navigate between the different versions of the same file.

Tagging of blog posts

Tagging was employed as the second level of semantic categorisation above the basic project construct. Tags could be applied within the system to all pieces of data (blog posts, people, files, projects). The interface employed an AJAX mechanism that allowed tags to be added relatively quickly. During the tagging process dropdown list of tags were displayed that matched the letters already typed by the user (predictive tagging).

The tagging system in Reasonate

The mechanism employed had a number of issues. Firstly the suggestion system was very basic and relied on initial user input to provide suggestions. This of course required the user to have a fairly good idea of what they wanted to tag in the first place. Del.icio.us employs a much more intelligent system where tags can be suggested to the user prior to any input being entered. This suggestion system however requires a unique fingerprint (in del.icio.us’s case the unique URL) and a large body of fingerprints/tags to search against. Within Reasonate this large body of fingerprint/tag combinations does not exist to search against plus the posts themselves hold very little characteristic information in order to automatically suggest tags based on the subject’s content.

The del.icio.us extension for Firefox showing tag suggestions (click to enlarge)

An interface issue was the fact tags could not be added to content as it was created. This was an application issue as the underlying tag data-structure required content to exist before a tag could be associated with it. This interface issue made tagging rather convoluted, content had to be created and then tagged in a two step process. A far more efficient and user-friendly process is to have content creation and tagging all part of a single step process.

Another interface issue was the single entity nature of tagging. Rather than using a basic text field and adding tags as a comma delimitated set of words tags were added one by one. In hindsight whilst arguably more aesthetically pleasing this process was slow and disjointed compared to the simple data-entry mechanism that is a text-field.

Finally yet another limiting interface issue was the minimal tag browser interface employed in the first half of the testing process. Rather than tag clouds or different lists showing personal, project and class tag lists the initial interface only listed a users personal tags and next to it a number indicating how many posts had been tagged with this item. This was very limiting from a functionality perspective as it did not allow for the simple browsing of team tags or relate this information to how the individual was using tags. These information issues came down to development time (or lack of it) and the necessity to develop other pieces of functionality such as the search engine before coming back to reassess user interface characteristics.

Indexing and searching of blog posts, tags and files

The search index used Ferret, a port of the Java Lucene search engine to Ruby (with a C search indexer backend). The search engine is very capable and allowed for different weighting of fields (tags given precedence), full text indexing of content and a complex boolean search query language. Overall implementation of the search engine went well and the resulting search capabilities were simple yet powerful. The degree to which this functionality will be used in the test environment is uncertain however given the short term nature of the project and limited quantity of data employed by the students.

The Reasonate advanced search interface showing the different options for finding things (click to enlarge)

RSS feeds of blogs and search results

All aspects of the Reasonate system are RSS enabled. Feeds can be generated for student and project output, search results, use of tags and changes to a particular file. Application of this functionality within the course was limited by two factors. Firstly most of the students worked side by side and as a result did not need to utilise RSS functionality in order to understand the progress of their team.

Secondly there was a technical issues regarding the use of RSS readers in the University and other locations. At the University RSS bookmarks were deleted when students logged out of their workstation. Consequently using RSS soon became a chore as each time the students logged in they were required to recreate their RSS bookmarks. In many other locations (such as office workplaces) students were not allowed to install third party software (Firefox/Sage) and as a consequence it was felt RSS could not be used. After these issues were brought to light a few online RSS readers (Newsgator/GReader) were illustrated to the students as a means of tracking project work.

RSS was very successful from an administration perspective however because both Mike and myself had well established RSS software and reading habits. Consequently it was easy to keep an eye on student output which assisted in the early identification of problem areas and low output students. From this teaching/supervising perspective RSS was very interesting. Rather than meeting with students at a specific tutorial time there was a greater sense that work was being evaluated continuously 'on-demand' so to speak. Following through with such a concept could be a very interesting way to run tutorials in the future, rather than paying tutors to be present at a certain place for a period of time emphasis could be placed on RSS based tutor support. Half a tutors time could be spent in physical tutorials whilst the remainder allocated for solving problems as they occur online.

Hierarchical commenting to blogs.

Easy commenting was important in order to establish a platform for post blogging discussion. Many blog posts require either some form of clarification or discussion between users following the initial action of posting to the service. The commenting system employed was hierarchical in order to distinguish between different discussion threads on the same blog post. I was concerned that comment threads could change subject or be commandeered by another user to promote ideas not related to the original post. To counteract this threat the comment field was kept relatively small in size in order to give the visual impression that comments should be quick and to the point.

Another feedback mechanism discussed but not yet implemented in the test environment is the concept of a Trackback. A trackback is a completely new blog post by another user (or the same user) related to the ideas of the original post. The new post notifies the original post of their actions through the use of a simple ‘ping’ action. This action notifies the original blog of the new post, its author and url. The system tracks these Trackbacks and displays them as a list of hyperlinks following the post. At this point in time Trackbacks have not been implemented and given that there is no demand from students for such a service they will not be added to the test environment. From a pragmatic perspective the hardest part about Trackbacks is not the technical implementation but explaining to users how and when such a feature should be used. The concept is difficult for many technologically savvy users to understand, let alone explain to a class of students who have only just begun publishing content to the Web.

Implementing the test environment

Most of the Reasonate functionality was in place at the start of the course (late February) after a brief but intense development period in late January. Commenting and search functionality where not introduced until mid-April primarily because for the opening month the emphasis was on getting the posting and project mechanisms working correctly.

For the first six weeks Reasonate was hosted on one of my own servers whilst the core system was built and the majority of the bugs ironed out. For the most part this hosting went well apart from a few Internet outages and one major hardware failure. Bandwidth was stretched in the final week of hosting as students, unaccustomed to the low-bandwidth nature of the Internet struggled to upload multiple 20-30 megabyte Powerpoint files to the server.

Following this period Reasonate was moved to an upgraded School of Architecture server. This move removed the bandwidth bottleneck but made management and regular backups slightly more difficult.
During this testing regular nightly backups were taken of the Reasonate database to allow for time-based analysis of data entry activity and usage trends at a later date.

Uptake

Students were slowly introduced to the Reasonate concept over a few weeks during the introductory tutorial process. A questionnaire for the students past computer experience has not been carried out but it is planned in the near future. From past experience however most students have little or no Web knowledge at the beginning of the course (learning about the Web is a primary factor for taking the course). Given this limited base of experience students were quick to take up the blogging aspect of Reasonate. For the tutorial process lasting three weeks most students averaged approximately four blog posts whilst some did far more.
After the initial phase of testing the following functionality requirements also became apparent:

Email notification of new blogs and comments

Students knew RSS feeds were available to the course co-ordinators and as a consequence assumed any piece of content they published was immediately read by those in charge or in their group. Consequently some important questions posed in blog content were not answered as quickly as possible by Mike and I. In our defense we were suffering ‘information overload’. 50+ students plus 30-40 other sites content is a lot of RSS content to parse and respond to regulary, especially when faced with a similar number of other communicae (in the form of emails, meetings, instant messages, mobile phone txt’s). Also it was found that in order to undertake digital conversations with or between students data had to be entered twice, once with the comment post and a second short email saying a comment had been posted. Otherwise the alternative was to just send an email and bypass the test system. In practice a method of capturing email collaboration would be the preferred solution but in the testing environment it was ideal for most Reasonate specific conversation to travel through the comments mechanism and be captured for later analysis. To satisfy these needs email notification of comments was added to provide the best blend of email’s ability to alert people and Reasonate’s capability to capture and search conversation.

WebDAV support for the project hand-in on student produced mini-websites

This capability was very course specific and added in order for students to create their own mini-websites and have them easily published to the Internet. In practice such a system would be of limited practical use and in many respects actually worked against the underlying principles of blogging where normal people do not have to worry about such things as Web naming conventions and html standards.

Whilst perhaps superfluous to the ultimate goal I did like the way WebDAV seamlessly integrates onto the users desktop (all the major operating systems support WebDAV file shares). This coupled with a versioned file-attachment system for blog posts would be very useful. In practice the WebDAV share would need to be read-only as the spec and its implementations do not provide for on the fly versioning of files but even then a file browser view of the latest project files as uploaded by participants would ease usability.

Wrap-up functionality to allow the simple aggregation of multiple blog posts into a cohesive story

This functionality is very important, so important in fact I will be giving this one its own post on this blog. Thinking about this started when a couple of things occurred. Firstly it was observed that most students were using the blogging system as a form of virtual scrapbook. Whilst most were blogging very regularly their posts were not a cohesive or descriptive as one would have imagined. In fact for the most part blog usage was quite different to general blogs you see on the web today. Rather than larger posts on a single subject many students blogs resembled stream of conscious thought process in a highly conversational (email) style. This was not a ‘bad thing’, we had on purpose left students free to develop their own blogs. Rather than returning with the more conventional long-hand style writing as employed conventionally the students had, either subconsciously or through peer observation, developed a very brief (one/two sentence) prose.

Mike’s observation at this was that he was not going to read through all these tiny posts in order to mark the project at the end. Initially we discussed using the student’s basic html web page submission as the venue for the summary texts for the blog but after a bit of thought this just felt wrong. The intention of Reasonate was to capture the design development process and to a certain degree we had. Ironically what we had captured was like any design development process, fragmented, terse and by itself not enough to understand the overall objectives, processes and achievements associated to the endeavour. What was needed was a mechanism easily ‘wrap things up’ into a format that was easily disseminated by the casual observer yet retained the rich chronological underpinnings the blogging process had successfully established….

Reasonate feedback from students on Tuesday 2nd May

David — Fri, 12 May 2006 00:52:57 +0000

At the end of the BBSc303 tutorial on Tuesday I held a feedback session with the students present regarding Reasonate, their experiences with it and areas that could be addressed. This feedback session was prompted following the observation that the tagging functionality was not being utilised by students as much as hoped.

My opinion of this was that the current usage pattern suggested a scrap-booking mentality by most students and tagging (if it occurred) would probably follow once the bulk of the modelling work was completed and the emphasis shifted to explaining the overall process cohesively.
The students present provided the following feedback:

Tags are not being used because:

There is tool little information to manage, it is “just the modelling process”.
Uncertainty existed over who the target audience was for the tags (personal, team members or tutors/markers?)
More comprehensive suggested tags would be useful to prompt the mind.
Presently there is no distinction between personal tag groups and the tag group within the project. This made collaborating using tags difficult (i.e. simple to-do lists could not be created or checked off using tags).
A question was raised asking why tags should be used when searching can be performed. What was not made apparent was the search engine index adds extra weight to tags hence the process of tagging improves search.
Problem: cannot tag when creating a document only afterwards. This was a pain to do.

RSS was under utilised for a number of factors:

Many groups worked side by side so the need for RSS was removed, looking over ones shoulder soon brought you up to date with project goings on.
The Victoria University computer system did not retain bookmarked RSS feeds on logout. Consequently students who tried RSS with Sage (an extension for Firefox) soon gave up because continually adding their bookmarks was too much work for too little gain.
Whilst approximately 80% of students where working from School others who were working at employers offices could not install third-party software (Firefox/Sage) hence they felt RSS was unavailable to them.
NOTE: Since this lecture to assist the students links to online RSS readers have been posted on Reasonate. These online readers are not as user friendly or useful as their desktop equivalents but it is an option for those wishing to try the concept out.

Other issues:

Incorrect knowledge assumptions existed between the administrators and the students in a few areas:

Many students did not understand the blogging toolset available
The blogging tools available allowed for the creation of hyperlinks, image references and complex formatting (like tables and anchor tags). As students had no experience with web design they did not understand what these tools meant or how to use them. Consequently blog posts were not as rich contextually and in the content they contained.
There was some confusion about the distinction between Reasonate and local/network drives. Some students did not understand how putting their work on Reasonate differed from placing it on a firewalled network drive.

A major usability issue with paging of blogs (or lack of this functionality) was brought to light during the discussion. This was a programming oversight and was soon added after the lecture.

Overall the feedback was useful and definitely highlighted a number of concept communication issues. The issues related to the use of tags was fairly similar to what I expected which was fairly reassuring on some level.