DuoMesh Project Blog

After extensive testing I have now removed the Beta tag from DuoMesh and I have now release it as final. The core features from the projects Aims and Objective have been implemented. This includes support for: text (e.g. blogs), audio (e.g. podcasts) and video based media (e.g. vidcasts). Towards the end of 2006 I did I have a list of possible features that I could integrate, but some of these proved to be too time consuming to implement.

The final list of features includes support for:

• Text based RSS and Atom Feeds
• Image based RSS and Atom Feeds from such websites as Flickr or Gallery
• Podcasts including audio and video formats
• Weather information

Enjoy!

A few users reported that not all Podcasts feeds were not compatible with DuoMesh. As mentioned in my previous post about Podcast feeds.

There were issues where feeds listed as Podcasts didn’t actually link to an audio or video file, which caused problems with the Mini Player, instead they linked to a web page. This caused me to recheck the Podcast function to make sure that it actually finds an embedded audio or video file.

Other problems where that if the Podcast didn’t have an icon or description it would break the whole websites layout, as there were open or unclosed div layers which caused the page to render incorrectly. Also users found that they were able to change their passwords without having to enter their current password, this posed a security risk as if a user were to select the “always remember me” option while logging in, another user using the same computer could change their password.

After 4/5 months of development I have released a beta/testing version to the general public at http://beta.duomesh.com. There were approx. 25 people that had joined the mailing list to keep updated with latest developments, so I have dispatched a email to allow for user testing and an option for them to take part in a user experience questionnaire.

This version is a fully functional prototype of how the end website operate and function. I will use the feedback to assess user reaction and first responses to the website. It will also help to iron out any bugs or problems that I have missed.

It will also allow for the rest of the time for me to concentrate on documentation and marketing.

Allowing users to add different weather information to their profiles was one of the feature I suggested early on in the project.

This has now been implemented using Yahoo! Weather’s API service and PHP Class “weather” by Matt Brown. This allows developers to access Yahoo! Weather services and pull information back into their own applications and easily customise the layout and design.

The only problems encountered with the implementation where the transparent weather icons in PNG format didn’t render properly in Microsoft Internet Explorer 6 (the problem didn’t effect IE7 as Microsoft new version of IE has partial support for PNGs) as shown in the image below.

This was fixed by using a CSS hack, this involved putting each of the transparent PNG icons into a div and setting the icon as a background image for that div layer. Then using a special filter command to trick IE6 to render the images correctly.

After getting standard text based feeds functional, the next steps was to get other feeds types supported. As feeds are generated/written in XML this means that the tags used in the markup language are not restricted liked HTML and users can create their own tags such as:

This could have been used to detect/or describe which kind of feed the user was adding/viewing (e.g. text based, podcast, image feeds). But due to the nature of XML there is no standardised way of describing if the feed they have added, is entirely image based or contains some kind of video/audio information.

This means that I will have to let the user choose what type of feed they are trying to add.

When developing the Podcast module I encountered a wide verity of problems, as the XML based feed for a Podcast is not widely standardised. Apple has made an attempt at trying to solve this problem, as their media player "iTunes" supports Podcasts, but will only accept XML that has been written to conform to their technical specifications. After adding wide verity of feeds I found that some podcasts didn't include the <description> which caused the layout of the site to break. Also some Podcasts would link the user to a web page instead of linking them directly to the MP3 audio file or video file. These things all had to be taken into account while debugging the code.

One of the major problems with designing a website is cross platform and cross browser support. I have been designing my website to meet W3C standards by using a mixture of HTML, XHTML, and CSS. Most modern browsers created within the last 2 years (e.g. Firefox, Opera, and Safari) support most of the standards set by the W3C.

I have aimed my website for use on browsers made within the last 3 years (for example Microsoft Internet Explorer 6/7, Mozilla Firefox 1/2, Opera 8/9 and Safari 1) and all current mobile phones/portable PDAs created within the last 2/3 years using XHTML and WAP (for mobile devices). Some browsers, however fail to render certain parts of the website correctly. Currently there is a issue with IE6 rendering an extra bottom border for image/Podcast module boxes.

These issues are usually fixed by using browser hacks, this works by using newer CSS standards that are not supported in older browsers. For example in CSS this is a perfectly legitimate CSS statement:

This is understood in pretty much every modern browser except IE6, which doesn't understand the element>child selection (e.g. html>body), so IE6 will ignore this CSS setting and default to whatever was set previously (e.g. just the #rss-container setting). Most of these problems are corrected by trial and error and extensive testing in different browser versions (by using Parallels Desktop, which allows virtual machines to be setup and used at the same time on my Mac Mini).

One of the major problems with the site at the moment is the loading times. When a user visits the site and they are the only user to view it within 30 minutes, some of the feeds may have been updated, by default Magpie RSS parser will check the last time the feed was cached (i.e. downloaded before and stored in memory on the server). If the RSS feed has a newer creation date than the last time the feed was cached the RSS extension will attempt to automatically download the feed again.

This could adversely affect the loading speeds of the website. As a user may visit the site and the RSS module will find that all the feeds have expired and will have to be updated.

I have found that sometimes the site will take upto 20 to 40 seconds to load, and in some extreme cases this times out the browser. Once the user has been to the site the feeds will have been cached and the site will load in less than a second. One way of resolving the problem would be to change the way the RSS module caches feeds, possibly by forcing the system to keep caches for up to half an hour to an hour.

Another way of increasing the speed and most likely the best way, would be to setup a cron job on the server. A cron job is like a scheduled task and can be setup to automatically load up the website say every 30 minute. This would take the loading off the user and system would deal updating the feeds.

The core feeds types that the script will support are:

• Standard text based feeds e.g. BBC News
• Image based feeds from such image galleries as Flickr
• Audio/Video based feeds such as Podcast like Diggnation (weekly technology video Podcast)

Other feed types:

• Email
• Weather
• Access to non-RSS feed information by taking a website and only stripping out the text

So far I have implemented standard text based feeds and image based feeds see: http://beta.duomesh.com for the latest development build.

After spending about 2/3 days testing and trying to implement OpenID into DuoMesh, I have managed to integrate with the login mechanism.

Registering with DuoMesh only allows you to use 4-15 characters and only contains letters and numbers, this prevents people from registering with a domain style username (e.g. users cannot register say duomesh.com as a username), this is how OpenID works, using a URL as a username. This means that I can simply use one login box to log both users registered with DuoMesh and people using an OpenID to login.  As OpenID passwords are verified by the identity provider, the password box is automatically disabled when a user starts typing a URL in to the login box, clicking on the password input box will prompt the user that they have entered (or started to enter) an OpenID and that the password is not required by DuoMesh (but authenticated via their identity provider).

Users from DuoMesh and OpenID are automatically entered into the same 'user' table, when a user logs in with OpenID the system will check to see if they exist in the database, if not the system will automatically create a new user with their OpenID as the username. The only difference between a standard account and an OpenID account is that the user of an OpenID account cannot change their password.

To show that OpenID is accepted on DuoMesh I have placed a small OpenID icon in the username field which will allow users to  identify that they can use their OpenID identity. This will also be displayed on the registration form, that registration is not required.

When creating a dynamic website, the developers need to take in to consideration abuse from spam.

Where the content of the website is subject to user submission, you run risk of getting abused by advertising, automatically submitted from spam bots, to promote their products and services.

To combat this potential problem an additional layer of security can be added to detect whether the client is human or a computer. This method is called CAPTCHA which is short for "Completely Automated Public Turing test to tell Computers and Humans Apart" [source: Wikipedia - 7 January 2007].

This approach usually involves supplying the user with an image, which they are asked to identify by typing a response to the image (e.g. supplying text as an image for the user to duplicate into an input box below).

There are a range of open-source scripts that work with PHP, that allows developers to integrate CAPTCHA into their script. The script that I have chosen to work with is called freeCap this provides users an image which they are asked to replicate into a box below.