Initial research into the techniques to be used for developing the pen drive has focused mainly on cross-compatibility. It has been found that the majority of the tools that would be considered for use on the pen drive are themselves not cross-platform as they are generally Windows .exe files. This means that building the same menu for use on alternative platforms could possibly reduce the usability of the Windows solution, and furthermore, building an alternative distribution for the Mac would be straightforward and more extensible. There seems to be little gain from designing a cross-compatible menu, when the programs on the pen drive are not cross-platform anyway, and could therefore hamper the quality of the menu.

Two techniques have been suggested for development: a web-based menu written in HTML and accessible through a browser; or a Windows application written in C#. After analysing these, it has been found that there is a clear preference, due to the reasons outlined below:

• If the menu were to be written in HTML and viewed on a browser, then a method of launching an application from inside the browser would have to be created.
• On a Mac, launching programs from a browser is impossible, meaning a user would would have to “download” it and run it themselves whenever they wanted to use that application, even though that app would be coming from their own pen drive. This would be a waste of time for the user, as the menu is designed to give quick and easy access to a suite of apps available to them on the pen drive.
• A further problem with launching apps from a browser would be that if the application was accessed from the Internet, rather than the pen drive, it would need to be copied to a local download folder or cache, which could cause licensing issues.
• On Windows, running a program in this way would throw so many security prompts that usability would be hindered, and in any case, it is not the role of a browser or HTML to launch applications. If this were possible, then the browser would have a massive security hole, as anything, including viruses, could be run from the browser.
• More problems with HTML seem to be that it would be problematic to download updates or new programs, as HTML code would have to write to a USB device.
• Additionally, a user could even browse away from the menu and access other websites, possibly without the understanding that in order to access the menu again, they would need to find the correct page in their browser’s history.

C# appears to have many advantages over HTML at present.  A menu written in C# will run on any Windows machine, and appears to be easier to make accessible. Usability would also be far greater when compared to an HTML solution as discussed above. A C# solution would generally be more extensible for future development, and additional features such as a repository of new apps or updates could be bolted on. Most importantly, a C# solution would not break any security model.

A Mac version is still possible, although advanced functionality such as adding additional applications would be difficult unless there was significant development time available.

We are going to try to develop early test versions in each format and see how it goes!