[MUSIC] Hi there, I'm joined once again by Dr. James Ohene-Djan from Goldsmiths College. And so the topic for this video is presenting your project. So how do we go about presenting our complete project, James? Where do we start? >> Well, one way of looking at it is as a technical showcase. So the showcase will consist of most probably a demonstration of the software, an overview diagram which will explain the major components of the software. And maybe a brief presentation, too. It's very important with a technical presentation to assume that most people know very little or not at all about what you've done. Often, when people do technical presentations, the big mistake is they assume that the audience knows as much as them. So it's very important to speak in plain English. It's very important to speak in a non-technical manner. And it's very important to not assume that people know what you're talking about before you start the conversation. >> So, and it's also important to know which details to put in and which details to keep out, and so that you can keep the presentation compact. So, if I'm thinking about a big piece of software that's got all kinds of modules in it. Maybe I can think about these prioritized user processes again and then go back to those, right? >> Absolutely, absolutely. One of the ways is to look at, say maybe our four or five main processes and concentrate on those. Don't try and add too much detail. But leave that for questions, or different comments that happen afer your initial presentation. Remember as well, people can't take too much information in at one time. So what you want to try and do is give them a broad overview of what's been achieve, and how it's been achieved. And then allow them to engage with you to go through and discuss how it works. >> Okay. And that's great, so we can describe our system, we can tell someone the sort of key processes they can go through. You can probably tell them a bit about some of the technologies that we've used and maybe, which were the best, most interesting packages we've used to give certain functionality and so on. But, how do we then sort of communicate maybe whether our system is successful or not. What do users think of our system? >> Well, there are two things. Firstly, we can go back to that task list, that process list, that we started off with in the beginning. And tick off all of the different tasks and processes that have been implemented. So we can literally demonstrate, or have users demonstrate, each of the tasks and processes we initially stated we were going to implement. So that's always a great place to start. >> So it's a checklist. So you've got the description of the process, and then a checklist to say yep, you can do this, you can do that. Yeah. >> Absolutely. What we also want to try and do is to find out what users think. >> Mm-hm. >> And one of the best ways of doing that is to get some peers to review your work. And I know in this particular course we're encouraging a lot of peer reviewing. >> That's right, yeah. Yeah. And also we want you to think about getting possibly your target audience, or whoever you can get to use your site, to give you some feedback from maybe a less technical perspective. Cuz obviously the people taking this project, they're all coding Meteor as well, right? So maybe it would be interesting to gather some feedback from just normal everyday users. And how might we do that? >> Well one of the best ways, and one of the traditional ways of doing it, is through surveys. So you could maybe just identify five questions, or ten questions. And then share those out digitally via email or by a form that you've built on your website and ask your friends, ask colleagues, ask peers to enter their views and their opinions on your survey. It's a great way of asking, and it's a great way of getting feedback on what you've done. What's really important of course Is always to remember that software can be improved, software can be developed. So listen out for what other people's feedback is. Listen out for what kinds of opinions and what kinds of suggestions they've got. They can all go into version two. >> And that all goes back into your development cycle. So if you really want to turn your project into a serious public application then all this feedback is gonna be really useful. And you feed that into your process and that helps set your tasks for the week if you're going to carry on. >> Yeah. >> Very nice. To just summarize, really, if you're gonna be presenting your project, try and make it as simple as possible. Try and maybe concentrate on one or two key messages, and maybe five key functions or tasks. Don't assume your audience has been with you on the journey of building this software. A lot of people do, and they find it very, very difficult then to express what they want to know. Let the audience lead the discussion about what is interesting or what is important and always be prepared to listen. [MUSIC]
