UCD School of Information and Library Studies IS30050: Information Architecture: Designing the Web

Transcription

1 UCD School of Information and Library Studies IS30050: Information Architecture: Designing the Web Module Coordinator: Dr Judith Wusteman Office: SILS 110, Tel: Office hour Semester 2 (Jan 2012): Wednesdays Table of Contents: page 1. Module description 1 2. Weekly activities and reading 2 3. Assessment 5 1. Module description Overview This module offers an overview of the concepts and practices of information architecture as it relates to the World Wide Web. Just as traditional architects seek to optimise the effectiveness, efficiency, and usability of living and work spaces, so information architects seek to create information environments that reduce barriers to communication and access, while improving the efficiency and effectiveness for all parties, including organisations and their customers, system designers and users. The focus of this module is on reinforcing best practices for information architecture by analysing and evaluating and suggesting improvements to web site designs. Course objectives By the end of the course, you should be able to o Understand the primary functions of an information architect o Understand the concept of Virtual Research Environments o Evaluate the usability of websites for a range of platforms, including PCs and mobiles o Document website user personas and scenarios o Understand the fundamentals of organisation, navigation, labelling and search systems and be able to apply these fundamentals to website design o Produce realistic information architecture reports o Design Blueprints and Wireframes o Create websites using Google Sites o Create website metadata o Perform Usability Testing Pre-requisites: No pre-requisites. This module complements IS30020 Web Publishing but either module may be taken in isolation. 1

2 Lectures The course will run in the second semester. There will be two lectures every week: Mondays Wednesdays Attendance at lectures Attendance at all lectures is compulsory. A register will be taken. Five percent of the final mark for this course will be allocated to class attendance. The attendance mark to be awarded for each lecture will be calculated by dividing the total number of marks (5) by the total number of lectures (24). You can be awarded a mark for a lecture you miss only if you provide a medical certificate or equivalent by the next lecture you attend. It is your responsibility to ensure that you sign the register during the lecture, particularly if you are late. It will not be possible to amend the register at the end of the course. It will be regarded as a serious disciplinary offence for any student to sign in for another student. Lectures begin on the hour and end at 10 to the hour. Consistent lateness to lectures will be and may be taken into account at the examination meeting at the end of the year. Lecture Slides Lecture slides are made available on Blackboard. You should print out the lecture slides so that you can annotate them during the lectures. Course communications Course announcements will be made via UCD official . It is therefore important that you check your UCD regularly. Other communications will be made via Blackboard (eg addition of new course materials). 2. Weekly activities and reading Reading You are expected to do background reading as recommended in lectures and/or Blackboard. You are also expected to purchase the course text: Morville, Peter & Louis Rosenfeld. (2007). Information Architecture for the World Wide Web, Third Ed. Sebastopol, CA: O'Reilly & Associates. ISBN 10: ISBN 13: Readings from this book will be set every week (see timetable below). You will not be able to successfully complete this module without doing this reading. 2

3 The Library has 2 copies of the 3rd edition in short loan and 3 copies earlier editions (but you would need to compare the earlier edition to the 3 rd edition and find some way of accessing a copy of the 3 rd edition for chapters that differ between the 2 editions.) If you have an iphone: Iphone app for $5 Edition/ _ html Timetable Week Topics Compulsory Readings Week 1 (16 Jan) Housekeeping, Module Introduction, Defining IA. All materials on Blackboard M&R Ch.1-4 Information Architecture entry in Wikipedia First 25 slides of the following electure (from IS30020 Web Pub module): www-and-ejournals/player.html (18 Jan) Introduction to assessment Week 2 (23 Jan) Virtual Research Environments (VREs) All assessment materials on Blackboard JISC: VRE Landscape report (Carusi and Reimer, 2010): OJAX++: Wusteman, J. (2008) 'Virtual Research Environments: What is the librarian's role?' Journal of Librarianship and Information Science, 40 (2): (Optional reading if you are on MLIS/GradDipLIS and are curious re relevance of VREs.) (25 Jan) Agile methodology Wusteman, J (2009) 'OJAX: a case study in Agile Web 2.0 Open Source Development'. Aslib Proceedings: New Information Perspectives, 61 (3): : Week 3 (30 Jan) User requirements Personas Scenarios (1 Feb) Organisation Systems M&R Ch 5 Personas: Scenarios: Week 4 (6 Feb) Labelling Systems (8 Feb) Labelling Systems (cont) M&R Ch 6 Jakob Nielsen's Alertbox: Top Ten Mistakes in Web Design (Nos 3 and 9) User requirements (due Monday 6 th February 8.00 am) 3

4 Week Topics Compulsory Readings Assessment component due Week 5 (13 Feb) Navigation Systems M&R Ch 7 (15 Feb) Navigation Systems Week 6 (20 Feb) Navigation Systems (and Blueprints) (Feedback on User requirements) (22 Feb) Navigation Systems Week 7 Wireframes (27 Feb) Googlesites (29 Mar) Guidelines on IA report assessment TEACHING BREAK Week 8 (St Patrick s Day holiday) (19 Mar) (21 Mar) Usability Testing M&R Ch 12, pp M&R pp Info Architecture report (due Tuesday 20 th March 5.00pm) Week 9 (26 Mar) Usability Testing (cont) Advanced Common Sense: Don't Make Me Think, Steve Krug, user testing chapters from edition 1 (chs 9,10,11) available at: (28 Mar) Usability Testing (cont) Mobile design J. Wusteman (2009) 'OJAX: a case study in Agile Web 2.0 Open Source Development'. Aslib Proceedings: New Information Perspectives, 61 (3): Available at: Week 10 (2 Apr) Mobile design (cont) Search Systems M&R Ch 8 (Feedback on Info Architecture report) (4 Apr) Search Systems (cont) 4

5 Week Topics Compulsory Readings Assessment component due Week 11 (9 Apr) Metadata (e-lecture) As 9 th April is Easter Monday, there will be no physical lecture but students are required to study the e-lecture on Metadata in their own time. (11 Apr) Search Systems (cont) M&R p 96 and p 194 Google Webmaster Central: /bin/answer.py?answer=35264 Ch 24 Getting people to visit HTML, XHTML, and CSS, Sixth Edition, Elizabeth Castro Google sites-based VRE (due Tue 10 th April 5.00pm) Week 12 (16 Apr) Search Systems (cont) (18 Apr) TBC Usability testing documentation (due Wednesday 18 th April, 8.00 am) Week 13 (23 Apr) (25 Apr) (Term ends Friday 20 April) Metadata (due Monday 23 rd April, 8.00 am) Week 14 (30 Apr) (6 May) (Feedback on o VREs o Usability testing documentation) Week 15 (Feedback on metadata) 3. Assessment Module Assessment 5% - attendance at lectures (as demonstrated by signing of the register) 95% - project Project objectives The objective of the project is to apply the skills of analysis, planning, research, design, testing and documentation learned throughout the module in order to produce a documented Virtual Research Environment for information architecture researchers. Googlesites The VRE will be created using Google sites ( This is a simple-to-use system and doesn t require understanding of HTML or CSS (hence those students who didn t take IS30020 Web Publishing last semester will be at no 5

6 disadvantage). The emphasis will be on the process of determining the appropriate site architecture. Submission All components of this assessment must be submitted via Blackboard. If for some reason, you have been granted permission to resubmit an assessment component, me and request that the initial submission be deleted so that you can resubmit via Blackboard. Never send assessments via . These will not count as submissions. Penalties will be applied for late submission (see below). However, given that the components of the assessment are cumulative, students are recommended to submit all components even if it is too late to receive credit for a particular component. Students must keep an electronic copy of all components of their assessment in addition to the copy on Blackboard, in case content on Blackboard is inadvertently lost. Reports Students must ensure that, where asked for a report, they do not submit an essay. Further details concerning the difference between reports and essays will be made available during the module. Realism Please read Overall Assessment Outline before attempting this component. In all components of the assessment for module IS30050, you should assume that you are an information architect working for a company that specialises in website development. Within this company, you are a member of a team that is creating a VRE for information architecture research groups. The audience for all the materials and documentation you produce are your team colleagues. Your materials and documentation should be realistic in relation to this context. You will lose marks for lack of realism, poor presentation or not sticking to required word or page counts. UCD Policy on Academic Integrity and Plagiarism Assessments must be the individual work of the student; group work is not acceptable and will be penalised according to the UCD policy on Academic Integrity and Plagiarism. UCD Policy on late submission of coursework 1 Coursework submitted at any time up to one week after the due date will have the mark reduced by two grade points (for example, from B- to C). Coursework submitted more than one week but less than two weeks after the due date will have the mark reduced by four grade points (for example, from B- to D+) 1 UCD's policy on late submission of assessment: 6

7 In other words, if you miss a deadline for submission, you may use the remainder of the week to improve your submission without additional penalty. Coursework received more than two weeks after the due date will be accepted but will be awarded a Fail grade. If you have agreed a late submission with me (for medical / other serious reason), please include a reminder to me of this under "Comments" in the assessment submission form (not via ). Project (and attendance) components Component User requirements Personas Scenarios Information architecture: Suggested organisation structure Navigation systems Labelling systems Blueprint Wireframe Percentage 10% 40% Metadata 5% The actual VRE, developed using GoogleSites 20% Usability testing 20% Lecture attendance 5% Project component 1: Personas and Scenarios Worth: 10% of assessment Submission format: One Word or PDF document with o A cover page o A separate page for each persona o A separate page for the scenarios Your full name should be included as part of the Word / PDF file name. Note: Please read Overall Assessment Outline before attempting this component. As with all components of the assessment for module IS30050, you should assume that you are an information architect working for a company that specialises in website development. Within this company, you are a member 7

8 of a team that is creating a VRE for information architecture research groups. The audience for all the materials and documentation you produce are your team colleagues. Your materials and documentation should be realistic in relation to this context. You will lose marks for lack of realism or poor presentation. Requirements: Requirement 1: Create 3 personas for the IA VRE that you are designing. Each persona should be maximum 1 page in length and attractively presented. You should aim to represent a wide range of typical users (all of whom should be researchers in Information Architecture) across your 3 personas but it isn t necessary to create profiles for every distinct user group. Take into account the guidelines given in lectures on the appropriate design of personas. Requirement 2: Produce a bulleted list of potential scenarios (that is, tasks that users of your IA VRE may want to perform). Only one sentence on each scenario; total length: between ½ and 1 page. Presentation Remember, as in most business scenarios, brevity is paramount. Apart from a (realistic) title page, the personas and scenarios should require no accompanying introduction. They should be able to stand on their own; if they can t, rethink your personas and scenarios. Project component 2: Information architecture report Worth: 40% of assessment Submission format: A Word or PDF document. Your full name should be included as part of the file name. Requirements: Students are required to submit a report covering the following Organisation structure Navigation systems Labelling systems Blueprint Wireframe Note: Please read Overall Assessment Outline before attempting this component. As with all components of the assessment for module IS30050, you should assume that you are an information architect working for a company that specialises in website development. Within this company, you are a member of a team that is creating a VRE for information architecture research groups. 8

9 The audience for all the materials and documentation you produce are your team colleagues. Your materials and documentation should be realistic in relation to this context. You will lose marks for lack of realism, poor presentation or for exceeding page counts. Report writing You are required to take into account the advice given on appropriate report writing in the lecture on this topic. A report is not an essay. As indicated above, the audience of this report are your colleagues on the web development team; the report should be designed accordingly. For example, o Your report should not include references to UCD modules, lecturers etc. o Your report should not attempt to explain the basics of IA. (We can assume that a professional team creating a website understand the basics of IA and don t need it explained to them.) o As a corollary, your report should not include quotes from textbooks (not even the Polarbear book). This means that you are unlikely to require a reference section in your report. o Your report should not be so general as to be of relevance to any possible website, but should be of specific relevance to the IA VRE you are creating. o Thus, it is unlikely that a general diagram taken from lecture slides or the web will be relevant. Any diagrams (and there should be some) should specifically describe some aspect of your VRE, not just IA principles in general. Suggested layout for report: 1. Title page 2. Executive summary 3. Table of contents 4. List of figures (if relevant) 5. List of tables (if relevant) 6. Introduction 7. Recommendations 7.1 Site Organisation 7.2 Site Navigation 7.3 Labelling 7.4 Blueprint 7.5 Wireframes Structure Structure is central to a successful report. Subsections 7.1 to 7.5 should be further subdivided and should include tables, figures, diagrams, bulleted lists etc as appropriate. Although bulleted lists should not be used as an excuse for vagueness, brevity is an advantage in reports. Assume that you are submitting this report to someone in your organisation who is very busy and would prefer, wherever possible, to glance at a well-structured table rather than a few paragraphs of text. Each of sections 7.1 to 7.4 should be between 1 and 2 pages long, including figures/tables etc. 9

10 Title page The title page should include the name of your VRE. Choose something realistic (not your own name!), snappy (not too long) and relevant (to VREs and IA). Executive Summary Your executive summary should be between ½ and 1 page long. Executive summaries come in a variety of formats. The format you are required to use for your IA report is: o A very brief overview of the report o Followed by a brief bulleted list of key recommendations Introduction The introduction should state the aims of the report and indicate what is in each section of the report. It should be very brief: max half a page. Recommendations Site Organisation, Navigation and Labelling Apply the context of VREs and the specific VRE you are creating - to every design decision. Demonstrate this in the report by appropriately justifying all proposals. Blueprint The blueprint should be a graphical view of the hierarchy of web pages (to include a legend), as discussed in the relevant lecture, not a more complex view of the site, as detailed in the course textbook. The simplest method of creating your blueprint is using PowerPoint. Ensure that the PowerPoint graphic is seamlessly integrated into the body of the report. Wireframes You are required to submit between 1 and 3 wireframes for your proposed VRE. You may use any software package that you wish to produce the wireframes. Ensure you follow the relevant guidelines given in the lecture on Wireframes. As discussed in the lecture, the wireframes should represent the structure of the main web pages of your site. Simple low-fidelity wireframes, such as the UCD home page example given in the lecture, will suffice. Remember that wireframes are not screenshots. Do not submit screenshots. You should not include content or graphical components as this may detract attention from the navigational and organisational components and the page overall layouts. How many wireframes to submit If all of the webpages in your VRE are to have the same overall layout, only one wireframe is necessary. If, like the SILS site, the front page will be slightly different from all other pages, two wireframes are necessary. If there will be an important page on your website that will be significantly different from the others (for some good reason), then you can submit up to three wireframes. 10

11 Remember that consistency is vital in web pages. You will not receive extra marks indeed you may lose marks - for submitting more than one wireframe if it is not obviously beneficial for there to be more than one page layout in your site. Presentation of Wireframes Remember, as in most business scenarios, brevity is paramount. Do not accompany your wireframes with an essay. Use callouts to add notes about functionality of page elements. Apart from this, and the obvious page titles and pages numbers, the wireframes should require only a minimum, if any, accompanying text. They should be able to stand on their own; if they can t, rethink their design. Relationship between components Remember that the overall objective of the project in this module is to produce a documented Virtual Research Environment for information architecture researchers. In other word, all components of the module should fit together. They are not unrelated exercises but components of one overall project. To keep you on the right tracks, imagine that you will be submitting all the components of your assessment to a client at the end of the module. Do the components fit together? Are they all describing the same system and supporting one another as far as possible? However, an aspect of Agile software development is the recognition that an understanding of user requirements evolves during a project. You will therefore not be tied down to o Assuming complete accuracy in the personas and scenarios you have created o Implementing in Googlesites every detail of the information architecture that you detail in your information architecture (IA) report. Acceptable reasons for minor differences in the scenarios predicted, the IA report and final implementation will include: o Recognition that a change in an aspect of the architecture or scenario would benefit the system. o An inability to implement a feature described in the IA report due to restrictions of GoogleSites. Any changed assumptions that you make between the scenarios/personas and the IA report must be listed and justified when submitting the IA report. Any changes that you make between the IA report and the final implementation must be listed and justified when submitting the Googlesites implementation. You will, however, receive a mark for each component based solely on that component and not on any changes you make in subsequent components. Any changes will be evaluated as part of the subsequent component mark. 11

12 Project component 3: Google sites Worth: 20% of assessment Note: Please read Overall Assessment Outline before attempting this component. As with all components of the assessment for module IS30050, you should assume that you are an information architect working for a company that specialises in website development. Within this company, you are a member of a team that is creating a VRE for information architecture research groups. The audience for all the materials and documentation you produce are your team colleagues. Your materials and documentation should be realistic in relation to this context. You will lose marks for lack of realism or poor presentation. Please refer to all relevant guidelines in the lecture on Google sites. Requirements: Create your VRE using Google sites ( Googlesites provides a series of templates for various types of website. Students are not to use any of these templates but, instead, to design their own templates from scratch. Any student found to have used a Googlesite template will receive a Fail grade for this component of the project. However, as explained in the lecture, students are allowed to use the templates available for individual pages (eg web page, announcements, file cabinet, list etc). Students are required to use Googlesites; alternative web site development packages or web editors must not be used, and additional marks will not be allocated for the inclusion in the VRE of advanced features not available from Google sites. Guidelines: Due to the lack of sophistication of Googlesites (or due to lack of time remember, this component is only worth 20%), it may not be feasible to incorporate all features in your Google sites website that you described in your IA report or illustrated in your wireframe. You will not lose marks for this if you do one of the following: Either: Within the submission form in Blackboard, submit a brief list of features that you mentioned in your IA report and/or your wireframe but that you weren t able to implement in Googlesites. It is not necessary to explain why you weren t able to incorporate these features. Or: Create dummy links to indicate where the relevant pages/features would be if they existed. There are various ways to indicate a dummy link; for example, the text can be blue and underlined. So, to indicate a link to a discussion forum on IA issues, you could include the following dummy link at an appropriate place on the page: IA Discussion Forum. 12

13 Or: Create dummy pages (empty pages with appropriate names) Ensure that your VRE is a suitable research environment for information architecture researchers. To ensure this, you need to understand what a VRE is (see relevant lectures and reading) and what sort of tasks a researcher in IA would want to undertake (again see relevant lectures and reading). Make sure that the site you create is specifically relevant to this purpose and isn t so general that it could be of relevance to any general audience. There is no upper or lower limit on the number of pages your website should include, as some students will include more features on one page than will others. However, in most circumstances, it is unlikely that a site with less than 3 pages would receive a good mark. Ensure that your VRE is interesting and attractive to its target audience. Include appropriate graphics such as a site icon etc. Make sure that any graphics aren t too big; screen real-estate is precious. Remember that a colleague will be testing your VRE in Week 11 or 12 so make sure that your VRE is interesting enough so that your tester will be able to comment on it. For example, add some sample content rather than just using greeked text. Submission You are required to submit the URL for your VRE. Under Assessments > Google sites > 2. Assignment materials > Submission, simply enter the URL for your VRE. No accompanying text is necessary (except, if relevant, a brief list of features that you mentioned in your IA report but that you were unable able to implement in Googlesites. In this case, brevity is desirable.) Project component 4: Usability Testing Worth: 20% of assessment Submission format: A Word (not PDF) document. Your full name should be included as part of the Word file name. Note: Please read Overall Assessment Outline before attempting this component. As with all components of the assessment for module IS30050, you should assume that you are an information architect working for a company that specialises in website development. Within this company, you are a member of a team that is creating a VRE for information architecture research groups. The audience for all the materials and documentation you produce are your team colleagues. Your materials and documentation should be realistic in relation to this context. You will lose marks for lack of realism or poor presentation. 13

14 Requirements: Students are required to carry out usability testing on their VRE and then submit a report describing that usability testing. As already discussed, you will be marked in this assessment on how well you carry out and document the usability testing. You will not be penalised / rewarded in this component for the quality of your VRE or for how many usability issues your partner commented on in relation to your site. Preparing for usability testing 1. Each student should choose a test partner from within the IS30050 module. You will be testing each other s VRE. 2. By the date agreed in lectures, one of the test partners in each team should have ed judith.wusteman@ucd.ie to let me know what 2 students are in your team. If you are finding it difficult to find a partner, please let me know immediately and I will pair people up. 3. Ensure that you don t show your partner your VRE before the test their first reactions are more valuable if they haven t viewed the site before. If, inadvertently, they do see the site before the test ask them to imagine they haven t! 4. Before the test, ensure you understand exactly what you are expected to do: a. Study the lecture on usability testing. b. Re-watch the sample usability test on the sensible.com site. c. Read the 3 chapters on usability testing from Don t make me think (as referenced in the lecture). 5. Remember realism: Your volunteer tester will be acting as a representative of the proposed audience for your site. In other words, you should both pretend that your tester is an Information Architecture researcher. Your tester should know enough about information architecture by now to be able to play the part. 6. Arrange a mutually convenient time(s) and location to perform the 2 tests (the test on your VRE and the test on their VRE). Ensure that you choose a quiet location and give yourselves plenty of time incase you over-run. Bring with you: a. Pre- and post-questionnaires b. A test script (adapted from Krug s) c. First reactions questions d. Key task testing scenarios e. Any necessary computer equipment f. Paper and pencil Preparing the documentation for the usability test As discussed in the lecture, you may use the materials from the OJAX usability tests as a guide in creating your questionnaires, scenarios etc. But make sure you don t just copy them. You must make sure your documentation is specifically relevant to the context you are trying to explore, namely a VRE for information architects. 14

15 Remember that, when I was user testing OJAX 2, I was testing a search engine interface not a VRE. o Your audience will be different (they will be academic information architecture researchers - think back to the personas you created). o Think about the function of your site. (Look back at your scenarios, IA report and wireframes) The context, content and users should have an influence on all aspects of your documentation. Additional advice on documentation: o Pre- and post-test questionnaires: o Test script: Include between 6 and 10 questions in the pre-test questionnaire. Ensure that they are all quick and easy to answer (mainly multiple choice). Include between 4 and 6 questions in the post-test questionnaire. These questions should give the tester the opportunity to discuss more widely so are likely to be mainly open-ended / free text questions rather than multiple choice. The test script can be largely borrowed straight from Krug (or my OJAX testing I borrowed from Krug too) but ensure that you customise where appropriate, for example, in introducing the VRE. Don t make unnecessary changes to the script. (Pretend that your tester isn t necessarily familiar with what a VRE is so give them a very brief explanation just a couple of sentences.) o First reactions questions: Again, these are likely to be very similar to mine, with obvious differences. o Key task testing scenarios: Include between 5 and 6 scenarios (which involve one task each). As with my OJAX scenarios, the majority should involve the tester actually doing something. (Scenario 6 in the OJAX test didn t involve actions make sure that you don t include more than one no action question.) The test Follow the process of usability testing as illustrated in the sample usability test on sensible.com (as shown in the lecture) but customised to your site s particular requirements: 1. Begin the test by reading your introductory test script. A very important part of this is to remind them to think out loud if they don t say anything, you won t have anything to use for your report! 2 OJAX is a search engine interface; OJAX++ is a VRE.. 15

16 2. If you are going to record the session in any way, ensure your tester signs an agreement form permitting this. 3. If the tester hasn t already filled in the pre-test questionnaire, ask them to do this now. If they complete it long-hand, you will have to transcribe their answers, so you might want to ask your tester to complete the questionnaire online. If you want to use something like SurveyMonkey, that s fine, but it s not necessary. A simple Word document is all I am looking for. (SurveyMonkey statistical graphs etc aren t going to be that useful with only one tester!) 4. Show your tester your site and proceed to first reaction questions. Remember to make a note of all comments and what your tester does (do they try clicking around? What do they seem to concentrate on? What confuses them? etc). You will find that negative comments from your tester can be more useful than praise at this point it will give you more to discuss in your report and more improvements to propose! 5. Move on to Key task testing. Again, make notes of comments and actions as your tester works through each of the scenarios you have set up for them. And, again, see note about the advantage of negative comments. 6. When they have completed the key tasks, ask them to fill in the post-test questionnaire. This questionnaire should prompt the volunteer to give their overall views of your VRE as well as any suggestions or views that didn t come out during the first reaction or key task phase. Timing A real test would probably take about an hour and you should reserve this amount of time as it will invariably take you longer than you predict. Remember to factor in time for your volunteer to fill in the pre-test questionnaire (they can do this beforehand if you prefer), to try out all your tasks, to fill in a post-test questionnaire and to give you any other useful feedback they can think of. Recording the session If you wish, you may like to record the test session so that you can study it afterwoods. ( is a popular online screen recorder.) But this is no necessary and looking/listening back can be time-consuming. Be realistic do you have time to do this? Making notes will suffice. Whether you decide to record the session or not, don t transcribe all the conversation. This is extremely timeconsuming, not to say time-wasting, and is not generally bothered with in real world usability testing. Just transcribe the really interesting / significant things the tester says. Summarise their other comments. Remember, this assessment component is only worth 20%. Let this guide the amount of time you spend in total on this assessment. Usability Testing Report Reports should be individual and produced by the student who created the VRE, not by their volunteer tester. Your tester should have no involvement in the report apart from filling in pre- and post-questionnaires, commenting during the actual test and providing any relevant feedback immediately after the test. 16

17 You should assume that you are an information architect working for a company that is creating a VRE for information architect research groups. Your report should appear realistic. You will lose marks for lack of realism, poor presentation or going over the prescribed word limits. Required layout for report: 8. Title page 9. Table of contents 10. Pre-test questionnaire 11. Test script 12. First reactions 13. Key task testing 14. Post-test questionnaire 15. Summary of usability issues and proposals Note: o The pre and post-test questionnaires should include your questions plus the tester s answers. o First reactions should include your questions plus a bulleted list of pertinent user comment and actions. Don t just transcribe user comments; summarise comments and, where appropriate, include some reference to what the user was doing when they were making the comments. It isn t necessary to list issues in the chronological order that they occurred. Max: 200 words. o Key task testing should include the scenarios plus a bulleted list of pertinent user comment and actions. Don t just transcribe user comments; summarise comments and, where appropriate, include some reference to what the user was doing when they were making the comments. It isn t necessary to list issues in the chronological order that they occurred. This component may be presented in tabular form if preferred. Max: 600 words (including scenarios). o Summary of usability issues and proposals should highlight the major issues raised by the test and make specific suggestions for improvements to the site. Max 300 words. o Of course, real usability testing would generally involve at least 5 testers and would be repeated at regular intervals throughout the development of your site. You are involving one tester and running the test only once so, in theory, results shouldn t be generalised and no conclusions could be made. To get around this, just include (once) in your Summary of usability issues and proposals the following phrase: We are assuming that there were 5 testers and they had all had similar comments/problems. This should be the only unrealistic aspect of your report! o Remember: the aim of the usability testing report is to provide a clear, easy-toread summary for you and your colleagues that highlights the usability issues uncovered and makes it as simple as possible for you and your colleagues in the VRE development team to decide what are the most pertinent usability issues that need to be addressed in the next version of the prototype VRE. o Usability testing is not a purely scientific process; conclusions are not statistically significant; common sense has to be the guiding principle on your report. If your report doesn t specifically state the main usability issues raised, but leaves the reader to try and work them out, then it s not a useful report. Remember, it is not meant to be a diary. You have a limited word count to work with. Leave out irrelevant details that aren t going to be useful. 17

18 Report writing You are required to take into account the advice given on appropriate report writing in the lecture on this topic. Structure is central to a successful report. Although bulleted lists should not be used as an excuse for vagueness, brevity is an advantage in reports. Assume that you are submitting this report to your project colleagues. They read usability reports on a regular basis - and they are very busy and would prefer, wherever possible, to glance at a well-structured table rather than a few paragraphs of text. Remember, less is often more. Look at each sentence you write. Does it actually say anything? Could it be written more succinctly? Project component 5: Metadata Worth: 5% of assessment Submission format: o Word (not PDF) o Your full name should be included as part of the Word file name. Note: Please read Overall Assessment Outline before attempting this component. As with all components of the assessment for module IS30050, you should assume that you are an information architect working for a company that specialises in website development. Within this company, you are a member of a team that is creating a VRE for information architecture research groups. The audience for all the materials and documentation you produce are your team colleagues. Your materials and documentation should be realistic in relation to this context. You will lose marks for lack of realism or poor presentation. Requirements: You are required to submit the following metadata. In all 3 cases, it should be appropriate for the home page of your VRE. Ensure that you take into account all requirements of such metadata as described in the relevant lecture. o Description meta tag o Propose a suitable value for the content attribute: <meta name="description" content=" " /> o Keywords meta tag o Propose suitable values for the content attribute: <meta name="keywords" content=" " /> o To include between 6 and 10 keywords o Title tag o Propose suitable content for the title tag: <title> </title> 18

19 Presentation Remember, as in most business scenarios, brevity is paramount. Do not accompany your metadata with an essay. Apart from the obvious page titles and pages numbers, the metadata should require only a minimum, if any, accompanying text. The metadata should be able to stand on its own; if it can t, rethink your metadata. The only exception to the lack of accompanying text should be if you need to add some comments about any design changes you have made between submitting previous assessment components and submitting the metadata. Only include comments if design changes have an impact on the metadata itself. Again, brevity is necessary. 19