paulcstephensen.com

Appendicies

Paul Stephesnen — Sun, 06 Feb 2011 05:26:09 +0000

Below is a list of all the appendices for my thesis as many people have been asking for individual copies. The table below lists the name of the Appendix, the link to the appendix and a summary of what is in the appendix and why I used it.

Appendix	Description
Appendix 1	Focus Group Summary Transcripts of the focus group summarised to document how I used direct feedback from the participants to discuss what type of ePortfolio system they wanted me to design for them.
Appendix 2 \| Interview with Tina	Transcripts of a semi structured interview with participant Tina. Tina is a pianist with musical interests in composition and music teaching. She was undertaking a masters of Arts music degree and also demonstrated a high level of comfort and competency with technology use in her practice. Tina was attracted to the project as she wanted to find a way of storing all her research in one online facility and completed all learning activities and completed their participation in the project as expected.
Appendix 3 \| Interview with Arthur	Transcripts of a semi structured interview with participant Arthur. Arthur is a male instrumentalist with interest in guitar, drums and the Irish rock genre and is aged in his early 40′s. This participant is technology confident with skills in Web design and computer programming. This participant is currently completing a doctorate of philosophy and was attracted to the project as he was interested in extending his network of websites and creating a centralised jumping-off point to other websites he owns.
Appendix 4 \| Mobile Learning Styles	A summary of a my meta-contextual review on Mobile Learning Styles. This meta-study, as referenced in Appendix 4 demonstrated that there is a change in how certain generations of learners are using mobile phones and devices to create, capture and share digital mobile content. This trend has implications for interactions and designers who may have to consider how they will integrate these technologies in Web 2.0 ePortfolio design. This appendix contains several long quotes which helped to evidence this trend.
Appendix 5 \|List of Content Management Systems Examined.	A simple list of content management systems I examined and links to website for each content management system. There are 30 open source content management systems listed.
Appendix Appendix 6 \| A list of the Content Management System selection criteria and test process	This Appendix has a table with a 16 step quick reference card for how to choose a Content Management System based on the criterion set by my key stake holders. Other Web 2.0 ePortfolio designers may find this a helpful methodology for adapting to their own projects.
Appendix 7 \| Software selection criterion	This table documents and provides evidence of the key stake holders requirements of the Content Management System that would be customised to create the Web 2.0 ePortfolio system.
Appendix 8\| Table 2.0 SoDaR by phase	This table was presented as away of documenting how I implemented the Software Development as Research methodology which was used for the enquiry part of this study. I have also used this table as a quick reference card for other Web 2.0 ePortfolio Designers who have asked me about implementing a Web 2.0 ePortfolio system.
Appendix 9\| Barrett’s Web 2.0 ePortfolios characteristics	Dr Helen Barrett’s helped to provide me with an informed context on the attributes that a Web 2.0 ePortfolio might have. This was a large document that was too big to fit into the main thesis but valuable enough for it to be included as an Appendix. Dr Barrett refers to Web 2.0 characteristics which are documented in this Appendix.
Appendix Appendix 10 \| Key Stake holders project requirements.	This appendix provides evidence of the Key Stake holders project requirements for the design of the Web 2.0 ePortfolio system.

Abstract

Paul Stephesnen — Fri, 22 Oct 2010 08:29:54 +0000

Title: Designing ePortfolios for music

postgraduate study. A practice-led inquiry.

sooner or later a tale of two e-portfolios systems from Paul Stephensen on Vimeo.

In this research I have examined how ePortfolios can be designed for Music postgraduate study through a practice led research inquiry. This process involved designing two Web 2.0 ePortfolio systems for a group of five post graduate music research students. The design process revolved around the application of an iterative methodology called Software Develop as Research (SoDaR) that seeks to simultaneously develop design and pedagogy. The approach I implemented to designing these ePortfolio systems applied four theoretical protocols to examine the use of digitised artefacts in ePortfolio systems to enable a dynamic and inclusive dialogue around representations of the students work.

The research and design process involved an analysis of existing software and literature with a focus upon identifying the affordances of available Web 2.0 software and the applications of these ideas within 21^st Century life. The five post graduate music students each posed different needs in relation to the management of digitised artefacts and the communication of their work amongst peers, supervisors and public display. An ePortfolio was developed for each of them that was flexible enough to address their needs within the university setting.

However in this first SoDaR iteration data gathering phase I identified aspects of the university context that presented a negative case that impacted upon the design and usage of the ePortfolios and prevented uptake. Whilst the portfolio itself functioned effectively, the university policies and technical requirements prevented serious use. The negative case analysis of the case study revealed that Access and Control and Implementation, Technical and Policy Constraints protocols where limiting user uptake. From the semi-structured interviews carried out as part of this study participant feedback revealed that whilst the participants did not use the ePortfolio system I designed, each student was employing Web 2.0 social networking and storage processes in their lives and research. In the subsequent iterations I then designed a more ‘ideal’ system that could be applied outside of the University context that draws upon the employment of these resources. In conclusion I suggest recommendations about ePortfolio design that considers what the applications of the theoretical protocols reveal about creative arts settings. The transferability of these recommendations are of course dependent upon the reapplication of the theoretical protocols in a new context. To address the mobility of ePortfolio design between Institutions and wider settings I have also designed a prototype for a business card sized USB portal for the artists’ ePortfolio. This research project is not a static one; it stands as an evolving design for a Web 2.0 ePortfolio that seeks to refer to users needs, institutional and professional contexts and the development of software that can be incorporated within the design. What it potentially provides to creative artist is an opportunity to have a dialogue about art with artefacts of the artist products and processes in that discussion.

A quick reference for interaction designers wanting to develop WordPress Weblogs for creative arts educational settings

Paul Stephesnen — Tue, 17 Aug 2010 12:59:26 +0000

Recently I was asked to provide some advice to a fellow interaction designer wanting to develop a WordPress system for a creative arts learning environment. I provided the following document which I hope can be used as a quick reference guide for other interaction designers. I hope this is useful for others interested in doing the same.

Summary of the challenges I faced.

When I first started the project with my supervisor I found that I was unable to install open source software on the web server that was provided to me. In line with Schöns action research method I had developed a methodology of studio based research which required me to download a number of open source content management systems which may have meant the requirements of the key stake holders. During this experimentation phase I discovered that none of the software I uploaded to the server would install. I would visit each vendor’s website and document the server requirements and make sure that server was compatible with server I was using. It was only after I contacted the faculty’s I.T support team that I identified the technical reasons as to why the server was not suitable for my project. I was advised that they would be prepared to help me have access to one of their servers for my project. The I.T support team informed me that I needed to ask another faculty based key stakeholder to officially negotiate access to the server. I set-up a meeting with the faculty based key stake holder who owned the server. This person was very helpful and supportive and they where impressed with the design of my project and allowed me to access their server as a shared resource. With the help of the I.T support team and the key stake holder my project was given special project status.

The downside to gaining access to this server was that the faculty I.T support team were not prepared to allow me to share the ePortfolio application with people outside the university. In the methodology section of my thesis I document the impacts of this policy implementation in the negative case analysis section of my thesis which highlights how this affected my participants and why they choose to not use the system. The ePortfolio system requirements to include the ability to leave comments, link to other websites, share the ePortfolio with external visitors and include content for Web 2.0 social networking websites such as Flickr.com, Facebook.com and Lastfm.com. While I had achieved the technicality of implementing this I found that the inability to share these functions had significant negative impacts on the up-take of the project. This was because WordPress had disabled the ability of for the embedding of external new media such as Youtube.com videos into WordPress. I over came this problem by modifying the code slightly as documented in the design outcomes section of my thesis.

The methodology I used to solve the problems.

Below I have included the methodology I included for implementing the software system that ran the ePortfolio system. It is relatively straight forward but not prescriptive and can be modified to suit your individual situation.


SoDaR by phase	Activity Description.
1.First Meeting with key stake holders	Meet with key stakeholders and identify educational outcomes and activity
2.Contextual Analysis	Identify key theories that relate to the learning task and contextualises the learning environment. Best Practice and Industry standards are also identified.
3.Identify Participants	Identify participants with key stakeholders
4.Administrative	Obtain ethical clearance Write project proposal Include budgets Identify technology needs for the project Talk to I.T support team to identify policy issues that may affect the success of the project. Identify Work Place health and safety policy Obtain ethical clearance from the client and your organisation.
5.Software Maintenance.	A focus group Participants gathered together to discuss what they wanted from an ePortfolio system. Document feedback from the interviews and focus groups and the function request1. Design Requirement Interface Feedback Add in Extra. Functions Request for Functions Test Functionality A focus group Design Requirements
5.Software Maintenance.