MPLAT

As we have the Smart Phones and the first application working it was time to share this with some of our partners as we get ready to deploy into the second phase at TVU.  Discussing the toolkit and application ideas as to how to ensure that what exisits will meet the needs of the TVU nursing students and their mentors means looking again at the assessment criteria that each School uses.  Where the School of Nursing and Midwifery uses the NMC Domains and Essential Skills Clusters as the main framework TVU use learning outcomes which we will need to map back to the Domains and Essential skills.  Doing this means that we will be able to use the exisitng application with some adjustments to terminology to make sure that what we have is appropriate to the different groups of students.

One of the suggestions from Obed was that there is a step which could be used before the students self assessment to assist them in determining their level of ability.  This may take the form of multiple choice questions with suggestions as to resources they can access prior to their practice experience so that they can develop their theoretical knowledge and have a solid base to make the most of their learning in practice.  Part of this will be the exisiting learning oppurtunities that make up a placement profile.  I have kept these purposely generic i.e. care of a patient post surgery to make sure that there is application to different areas and specialities such as the patient post cardiac surgery can be added by the mentor when creating the placement profile.

Another area which we discussed is the deployment into areas where TVU nursing students will be going in May 2008.  Our experiences from the current deployment are that participants need the time to get used to the technology before asking them to use the applications.  This will mean loaning the Smart Phones to particpants prior to the placement so that they have time to faamiliarise themselves with how the Smart Phone works and for some this is a daunting task in itself.  Many of take for granted that people have an use computers, mobile phones etc and can use them but many people actually don’t and sending a text can be a major event.  Imagine giving these intelligent people a completly alien piece of equipment and ask them to use it, fear is a common problem.  Overcoming this will involve training on the Smart Phone and then the applications, allowing people the oppurtunity to become comfortable and a part of their world.

Part of the development of the toolkit is to understand what mentors and students in practice actually want.  In order to achive this a sample of students and mentors were spoken to and their ideas noted to inform development.  The main suggestions and wants from students were the ability to find information on specific conditions such as surgical terms when they wanted to rather than wait to access a computer or a text book, a way to keep in touch with collegues whilst in placement and some where to keep notes (replacement for the standard note pad). 

The mentors had slightly different ideas of what they wanted and having access to the internet was not a big a priority as time is limited when working in clinical practice.  They valued the ability to see how the student is doing and communicating with them although struggled with the added value of having a mobile toolkit to do this.  This is something that we will be looking at as time goes on, what is the added value of having a mobile toolkit for mentors in clinical practice?

Watch this space.

Using Visual Studio 2005, the process of creating an installable CAB file for a mobile device project is very straightforward. The steps are as follows:

1. Add a new Smart Device CAB Project to your solution (Project Types -> Other Project Types -> Setup and Deployment -> Smart Device CAB Project)

2. Right click on the project in the solution explorer and select View -> File System

3. Double click on the Application Folder. This is where your generated .exe or .dll files will be placed. To add your application, right click the Application Folder and select Add -> Project Output

4. From the Add Project Output Group window, select the project you want to add, and highlight Primary Output. Click OK.

The project and required .dlls are added to the application folder.

5. You can create program shortcuts in other folders on the device by selecting the folder (to add a folder, right-click File System on Target Machine and select Add Special Folder -> {the folder you want to add}), and right clicking inside the folder view panel. Select Create New Shortcut.

6. From the Select Item in Project window, browse to the Application Folder and select your project’s output. Click OK.

7. Rename the shortcut to whatever you would like - it will appear in the folder on your mobile device with the name you specify, and the icon selected in the project’s settings.

8. Build the project to create the CAB file.

The CAB file can be copied to your mobile device and installed by running it on the device.

In part 2, the CAB file will be added to an installer that can be run from a desktop machine, and will copy the CAB file and install it via the built in ActiveSync installer.

To improve the layout of our Pocket PC forms, and in particular to address the issue of ensuring we have forms which are viewable in either portrait or landscape mode, we recently moved all the controls on each form into panels. This lets us anchor controls to panels rather than forms, which means that our layout is not disrupted when switching from one mode to the other.

We did this by cutting and pasting the controls for each form - initially we cut all controls, then pasted them in a containing panel. For each panel to be added, we would cut the controls that were to exist in the panel, add the panel, then paste the controls again. This was a quick and easy way to update our forms. It was not issue free, however.

When a control is cut from a form, it seems that the definitions of any event handlers associated with it are removed as well. This meant that all our buttons and combo boxes were no longer functional.

Fortunately, the code for the event handler was still in the class for the form - all that was missing was the definition of the event handler. The workaround for this is very simple, which alleviates some of the *sigh*-factor from this niggle.

The workaround is:

1. Finish the layout first. This workaround is far easier if you do all controls at once
2. Double-click each control in the designer to create new event handlers
3. The new event handlers’ names will look like: someButton_Click_1(object sender, EventArgs e). So open the code for the form’s .Designer.cs file (e.g. Form1.Designer.cs), and do a quick replace (Ctrl+H), replacing “_1″ with no text (obviously, if you have used “_1″ in your design element names, you will need to replace each event type individually - replacing “Click_1″ with “Click”, “SelectedIndexChanged_1″ with “SelectedIndexChanged” and so on).
4. The newly created even handlers in the Designer.cs file will now point to your pre-existing code. The last step is simply to remove the “_1″ event handler methods the have been generated in your form’s .cs file (e.g. Form1.cs).

In developing our application on the Windows Mobile platform first, we have found some advantages that have allowed us to sidestep potential time-consuming problems.

Being unfamiliar with the .NET platform, we have been making use of code samples in books and online to help us find ways to achieve our ends.

Familiar with the method of writing an object as a binary file in Java, we felt that this would be an easy way to persist the self assessments, placement profiles, and action plans created by the application. Sample code was available (as is often the case) for .NET ina number of places. The libraries required for this, however, were not found in the Windows Mobile platform.

Had we developed a desktop application first, and then attempted to port it to the mobile platform, we would have found ourselves with a serious problem, whereby the desktop application was able to handle objects saved as binary files, and the mobile platform was not. This would have required a rewrite of the desktop application as well as our ongoing work with the mobile application.

It may well be that the libraries are available somewhere within the mobile platform, but the key issue here is that the same code would not work on either platform. Our aim is for as much reuse as possible, particularly in key areas of business logic and file I/O.

As it is, we have code that we know will work with both platforms - our files are now saved using the incredibly simple XML serialisation library - and have therefore saved considerable development time.

An argument could be made that where a team is developing for different platforms, initial development may well be better spent working with the less-featured platform first. This way time is spent finding a way that will work - optimisation and additional features can be added if deemed necessary, for certain, but this will not be done at the expense of functionality - a seemingly very Agile approach to take.

Our device choices were determined, after price per unit (of course!), by the following:

* The OS Platform - in this case, for data replication / asynchronous transfer we chose Windows Mobile

* Communication features - we wanted as many options as possible for the device to be able to be networked rather than just a device running an application. We wanted PDAs that had SIM card capabilities, in particular - the ability to use the device as a phone and make use of GPRS and 3G as an alternative to other networks makes this a very desirable feature to add to infrared, bluetooth, and wireless.

* Input options - on mobile devices this includes touchscreens / stylus / bluetooth keyboards / sliding keyboards / docking stations

* Storage options - removable storage would increase usability as files would not need to be transferred via a network

* Other built in features - things we felt could be useful in future development of the toolkit, in particular features that would aid documenting of evidence, such as sound recording, and camera / video functionality.

The project proposal has now been submitted both to the School of Nursing’s ethics committee as well as NREC.  Once approval has been gained from the School we can start with the pilot deployment of the toolkit and once NREC approval has been gained we can start approaching NHS staff to participatein practice.

More information on applying for NHS ethical approval can be found at http://www.nres.npsa.nhs.uk/ If anyone is about to start a project I would recommend looking at this site early on in your process and there is valuable information.

The next step is to refine the simulations that we will be using to pilot the tool.  The plan is to ask a small number of students and mentors to work in the Virtual Interactive Practice Suites that we have in the School of Nursing and Midwifery, University of Southampton as they would do in practice.  This pilot should give us some rich data with which we can further develop and refine the toolkit before deploying in clinical practice.

We have finished iteration 1 and 2 which includes database setup and queries, model to code, investigation of visualization API, implementation of student self assessment. The graph below shows the application interface of student assessment. It gives rating for each proficiency and show related sub-proficiencies. Comment can be given text free input. The similar function also applies to placement profile.

We are now heading on iteration 3 and will use some graphical toolkit to visualize the Proficiency-Skill networks.

We have been developing the various parts of our application in separate projects under a Visual Studio ’solution’. These parts represent separate areas of programming focus, for example:

• database functions
• data objects (common classes)
• GUI
• file I/O

Deploying to a mobile device like this causes some problems. It seems that each project that is deployed gets certain .net framework dlls deployed with it, and these all take up space as each project is deployed.

The SQLServerCE object has some issues anyway regarding the error message we were getting, so it was helpful to address everything at the same time. Closing a data connection and data readers apparently does not dispose of the objects, or pass them to garbage collection - they need to be explicitly disposed, which is slightly unusual for .net programming.

Having applied these changes, we found we were still running out of resources. We combined our code into one project, and deployed that happily. It seems that for mobile applications, separate dll projects are not a good idea, so we will be developing our application slightly differently from here on in. We will still use separate projects to build up code, and conduct spike tests, however, because this will give us all the benefits of the object-oriented approach, especially as far as testing specific bits of code.

Our preliminary story board gives a basic idea about user interface. We mainly use tabs to show the functionalities. Tabs give direct and clear view of our space, especially when the application is deployed on small screen devices. Based on our use case and activity diagram analysis, students and mentors need to get guidance, placement information, identify learning opportunity and action plan, etc. , which are shown by several tabs:

The Self Assessment and Learning Opportunity tabs could be combined with an Identify Learning Needs tab. We are still thinking of effective ways to show links between Learning Needs and Action Plan (e.g. clickable mapping forms).