Monthly Archives: December 2013

The new computing curriculum and web science

There have been many arguments over the new computing curriculum. The more I look at it, the more concerned I am that it appears narrowly focused on programming, whereas computing can involve so much more.

 

One case in point is the course I’m currently studying at FutureLearn, the Open University’s contribution to the MOOCs (massively open online courses) currently sweeping the web. This particular course, sponsored by Southampton University, is called Web Science: how the web is changing the world. It looks at the effects the world wide web is having on society, and how we have influenced the web.

 

The topics it covers are ones that are important to understand, and that I spent time in the classroom trying to get across – that technology is new, but pervasive, and affects our lives in more ways than we can imagine. In fact, the same topic is covered in a book I’m currently reading in order to review: Digitized: The Science of Computers and how it shapes our World.

 

If children are truly to understand the importance of coding, and to be able to express themselves effectively using digital media, then they also need to understand the deeper concepts of computing, for example how it can help us to build a better world, and to better understand our own minds.

 

I haven’t done much resource creating for the past few months as I left my teaching post in July and have been focusing on other aspects of my business, but after a break away from classroom technology and learning for a bit I’m now getting restless and starting to look for ways that I can help schools make the move forward from office-based computer skills to real computer skills. If anyone has any suggestions – or anyone in the Canterbury, UK area (or online) would like practical help – then please do get in touch. I will be resuming my quest to produce teaching materials in January, but not being in a classroom regularly makes it a little harder to keep up with the practical side of things.

 

Incidentally, there’s another MOOC coming up that ICT teachers really should be seeking out: Teaching Computing part 1 (part 2 to follow) from the University of East Anglia, which aims to prepare teachers to teach the new computing curriculum in both primary and secondary sectors. The course lasts for 4 weeks and is expected to take up around 4 hours per week, but of course anyone seeking to teach computing should be prepared to devote time to it – my biggest fear is that computing will go the way of ICT, with too many non-specialists stumbling through and not giving the subject the rigour that it deserves.

 

How do I beta?

Please note that this is how I personally work – it isn’t a rigid way that the job must be done. I suspect there are as many different ways of working as there are beta readers. Also, this service is bordering on an alpha read or critique, rather than just a beta read.

 

When an author contacts me I’ll book them in and let them know when I expect to get to their project. Sometimes I can take one on immediately, while at other times I’ve run a waiting list of up to six months. When I receive the file, either in  Word or PDF version, I start an Evernote file for the work, giving title, author and page count (with word count if known). I add any synopsis or other information I’ve been given, plus any specific things I’ve been asked to look out for. I put the date I received the file and any deadline or estimate for finishing. I also confirm to the author that I’ve successfully opened the file and saved my own copy to work on. It helps if I also have some information on the writer’s experience and their intentions for the manuscript (generally, seeking an author or self-publishing).

 

As I read, I make notes in the project file – like a running commentary, on something I don’t understand, something that makes me laugh, something that’s inconsistent… I’ll also add general comments in the Evernote file under heading such as Setting, Plot, Characters, POV.

 

At the end of a session I’ll note in the Evernote file where I’ve stopped, and I’ll also summarize what’s happened in this session, so it’s easier to pick back up after a day or so away. This is also a good way of assessing the plot – is it easy to say what happened in each chapter? Did too much happen to explain quickly? Did things just drift along with nothing really happening at all? Is it clear at this point what the main character wants and what’s standing in their way?

 

I try to read at least 50 pages from a project in a session. Any fewer and it takes too long to get through, and it also becomes bitty in my mind and hard to keep straight. Any longer and I lose concentration – although if a book is close to the end of the development cycle and there is less to comment on I can become more involved and get further in the session. I might switch projects and continue if I still have time available, but I have to be aware of other work that has to be done as well, and in order to keep the beta fee as low as I can, I have to prioritise the higher-paying work.

 

When I’ve finished a project, I’ll wait until the next day to compose a report for the author. This allows my thoughts to gel. Sometimes I’ll go back and re-read the opening, adding a couple more comments – things that were unclear to start with sometimes come clearer on a second read, or things that seemed unimportant are noticed more – or important things are missing.

 

I’ll then write back to the author, attaching the project file with the comments, and include a general report as well. Sometimes the author has further questions for me, and I’m happy to carry on the conversation with them, and clarify anything. However, it’s entirely up to them what notice they take of my feedback. I also focus on finding and explaining problems, rather than how to fix them.

Beta reading is not like normal reading

For a start, I can only beta read either on my computer or on my laptop, so I can add comments. Beta projects are often unpolished, and therefore do not flow as easily as finished works, and this can slow down the reading considerably. I’ve had projects where I’ve had to train myself to ignore punctuation because, the use of commas, is fairly arbitrary making it, impossible to use it to, help with understanding.

 

I often have to go back and re-read sections, especially in the first few pages. What have I taken in? What have I missed? Has the author introduced too many characters too quickly? Is there too much background information given, rather than getting straight to action?

 

I’m constantly questioning what I read, and this means that I have to check facts – what exactly was she wearing? Did we get told she changed clothes? Is it possible she changed but we weren’t told? How many days have passed? What day of the week does this work out as?

 

This means that beta reading takes far more time and concentration than normal reading. It is not a way to get free books to read! It requires time and patience, and a good understanding of how books should flow. It requires tact and patience in explaining issues to the author. I am not – at that point, at least – the book’s editor or proofreader, and I will not point out every single mistake (more on the different roles in another post) but I will point out consistent errors and issues, and I will point out when a sentence does not get its message across clearly. I can pick up dictation errors if the author has used dictation software. I will point out where punctuation/grammar obscures the meaning. I will also point out general writing weaknesses, such as inconsistent points of view or over-reliance on adverbs, if necessary.

 

The read is focussed on the structure of the story, and while it is not in the depth required by a developmental or structural edit, it should provide plenty of information to help you identify the strengths and weaknesses of your novel and point you towards how to improve it.

 

All this makes for an enjoyable but challenging way of helping authors to produce their book. It is also a good way for the author to get to know the way I work, and for me to get to know the author and the story, before discussing any further editorial/proofreading work they may require. Part of the beta fee may be deductible from the final fee.