Reflective reports 101

By Gordon Rugg

 

There’s a widespread belief in education that getting students to reflect on their learning is a Good Thing. Whether this is actually true or not is another question, for another time. The key point is that if you’re a student, you might well end up having to write a reflective report.

This experience can be challenging, especially if you’re in a discipline like computing, where you might not have expected anything quite so introspective. It’s particularly challenging if the reflection is about a piece of groupwork, as numerous memes about “What I learned from groupwork” will testify.

Many students under-perform when doing a reflective report. However, if you follow a couple of simple principles, then writing the reflective report becomes a lot easier. As an added bonus, there’s a good chance that you’ll get better marks, and even learn something genuinely useful from the experience.

So, what are these principles, and how do you apply them? They involve systematically describing choices. Here, by way of moral support, is a picture of someone making a choice. You may be reassured to know that the choices you’ll be working with are a lot more encouraging…

By Viktor Mikhailovich Vasnetsov – The knight at the crossroads

https://commons.wikimedia.org/w/index.php?curid=800287

Advertisement

What academic writing looks like

By Gordon Rugg

Students often ask what good academic writing looks like. It’s an important, simple, question. Answering it in words is tricky. However, answering it with words plus highlighter makes answering easier. The answer is that good academic writing features mainly highlighter 2, with some highlighter 1 at the beginnings or ends of paragraphs, and as little grey as possible.

What does that actually look like? I’ll use a worked example to illustrate it, on the topic of the growth of the Internet. This is a difficult topic, because the key points are well known to the general public, so there’s a real risk that your opening text will look like something that a twelve year old without Internet access has hacked together at the last minute for an overdue essay.

Referencing

By Gordon Rugg

So what is referencing anyway, and why should anyone care about it? What’s the difference between the Harvard system and the Vancouver system and the assorted other systems? How do you choose references that send out the right signal about you?

The answers to these and numerous other questions are in the article below. Short spoiler: If you do your referencing right, it gets you better marks, and you come across as an honest, capable individual who is highly employable and promotable. Why does it do this? Find out below…

Iterative non-functional prototyping

By Gordon Rugg

Sometimes, product development is straightforward. The client tells you what they want; you produce it; they’re happy with it, they pay you, and everything is fine. This is known in the field as the waterfall model of development; once the client has signed off on the requirements, the process then moves irrevocably onwards, like a river going over a cliff.

When you and the client are dealing with familiar territory, this approach usually works reasonably well. Sometimes, though, things don’t work that way. You’re particularly likely to hit problems when you’re developing something that’s new territory for you and/or the client.

One common problem involves the client changing their mind part-way through development.

Another involves the client being unhappy with what you produced.

Communication problems are another frequent source of trouble, with you trying to make sense of just what the client wants, and getting more and more frustrated.

If you’re in that situation, or you think there’s a risk of getting into it, you might want to try iterative non-functional prototyping. It’s a lot simpler than it sounds, and it’s a fast, cheap, efficient way of getting to the heart of what the client wants, particularly when clients don’t actually know just what they want at the start. It involves looping through mockups systematically until the requirements are clear.

This article gives a short introduction to the core concepts and the process. It should be enough to let you get started; there’s supporting material elsewhere on this blog which goes into more detail about the underpinnings, which I’ve linked to within the article.

Waterfalls and loopsImages from Wikimedia Commons: Attributions are given at the end of this article

Getting an overview of the literature via review articles

By Gordon Rugg

Review articles are an extremely useful resource when you’re starting a literature review, and when you’re about to start some new research. However, most students have never heard of them.

In today’s article, I’ll describe what they are, how to find them, and why they’re so useful.

Finding the right references, part 2: Getting a first overview

By Gordon Rugg

In a previous article, I looked at some issues that affect how and why finding the right academic references can be difficult. In today’s article, I’ll look at how to set about finding those references, beginning with the familiar problem of reading lists.

Some lecturers supply reading lists; others don’t.

Reading lists can be very comforting, because someone else has already done the thinking for you, and has told you what you need to know. There’s also the nice implicit message that you only need to know what’s on that list, so there’s a limit to the work ahead.

It’s a comforting feeling while it lasts, but there’s usually a small voice at the back of your mind asking what will happen when you leave university and enter a world where nobody is likely to give you a reassuring list of the things that you need to know.

Which brings us back to the lecturers who don’t supply reading lists, and who expect you to find information for yourself, with only a few words of guidance, such as “Weber’s work on bureaucracies is the place to start” or “Good question; that’s a classic sociotechnical problem”.

Where do you go from that sort of start? Your friendly librarians will usually be very happy to give you good advice about how to locate information online, and often, that advice will find you exactly what you want. However, there are some other quick and dirty methods that you might find useful. They’re what this article is about.

Design Rationale, part 1: A tale of reasons, raccoons and cat flaps

By Gordon Rugg

Often, a small example can give key insights into bigger, deeper questions. The saga of our cat flap is one of those cases. It’s an apparently trivial problem that leads swiftly into important, difficult questions like how to tackle design decisions, and how to identify design options that you might easily have overlooked, and how to spot design problems in the first place.

That’s how we ended up as one of the few the families in England to have a raccoon flap in their back door, rather than a cat flap. It’s an excellent example of design rationale – the reasoning behind a particular design decision. Like most problems involving design solutions to client requirements, it takes us into the difficult territory where human beings have trouble establishing just what they want and why they want it, and where designers are trying to find a way of tackling the problem that’s systematic but that can also capture the often messy requirements and constraints affecting a particular problem.

I’ll tell the cat flap story first, and then work through the insights that it gives about design rationale.

The observational techniques

By Gordon Rugg

Sometimes you can get the information you want via interviews and questionnaires. Often, though, you can’t.

For instance, if you want to know how long the average visitor spends on your website before leaving it, or what percentage of the population don’t have current car tax displayed in their car, or just how a skilled tennis player holds the racquet for a forehand, then interviews and questionnaires won’t get you very far.

In cases like the ones above, you’re trying to find out what people actually do, as opposed to what they say that they do.

There are various techniques that can be used for this. I’ve grouped them together under the label of “observational techniques”.

Our main posts: An overview by topic

By Gordon Rugg

This article gives an overvew of our posts so far on three main areas.

Two of these are about research methods and development methods, namely elicitation methods for gathering client requirements, and systematic approaches to visualising information.

The third area involves our Verifier approach for tackling long-standing problems, which we’ve applied to the Voynich Manuscript and to the D’Agapeyeff Cipher.

All the material listed below is copyleft Hyde & Rugg; you’re welcome to use it for any non-commercial purpose (including lectures) provided that you include the “copyleft Hyde & Rugg” acknowledgement with any material you use.

Gathering and clarifying client requirements

We’re posting a series of tutorial articles on a wide range of methods, and articles about the bigger picture of requirements gathering. The main articles that we’re posted so far are as follows.

Knowing the unknowable, revisited: Why clients can’t know their requirements, and some ways to fix the problem

By Gordon Rugg

Why don’t clients and customers make their mind up about what they want?

There are several reasons, all of which make sense in hindsight, but that aren’t immediately obvious.

This article is a short introduction to one of those reasons, that can be handled swiftly, cheaply and easily. I’ll return to this topic in more depth in later articles.