Now, after 25 years, I’m as much of a cynic about Far Eastern learning methods as you can find even in the darkest recesses of the staff room. But, there’s some interesting stuff to be seen here:

there’s proper research with control groups and a decent sample size and all going on. That’s promising;

the research needs to carry on for another 4 years. That’s also promising and suggests this isn’t just another attempt to force another fad down the throats of teachers;

the apparent gain after a year was small;

the curriculum being modelled is dealing with depth and mastery rather than simply adding a whole pile of content.

The first three points are interesting enough, but it’s the last one I need to focus on.

The current UK government seems to be insistent on adding massive swathes of content to our GCSE and Key Stage 3 curriculums. The Science GCSE drafts, for example, contain massive amounts of knowledge content which will need to be rote learned – I mentioned yesterday about Newton’s Laws and a whole pile of formulae. This seems, to me, to be at odds with the Far Eastern mastery style of work, where less needs to be learned but it needs to be understood and applied more broadly.

Take, for example, the “Hannah’s Sweets” GCSE Maths question (Edexcel, June 2015). I heard, like everyone else, about the Twitter furore brewed up by 16 year olds who couldn’t do it. But it’s exactly the sort of question that anyone who’s been taught to master Maths should be able to do – as opposed to the teaching to the test methods we seemingly use just now far too often. I’ll admit to looking at it and wondering why on earth it was in any way difficult – but I guess my maths isn’t too sloppy.

So – mastery or death by content?

I know which I’d prefer. I also know darned well which I’ll be getting. And I’m not happy at all.

I’m a teacher, of course. Doing interesting (usually, I hope) things with computers. Which, naturally, changes all the time.

One of the many things that change is the things we have to teach and the ways we have to teach them. Driven by our government – the one that tells us that making schools semi-privatised academies is good because schools know what their kids need best but then turns round and tells us exactly which classes every child has to take.

Just now the thing seems to be knowledge and rigour. Because it’s really good for children who are growing up in the age of Google and embedded computing if you make them learn a whole pile of stuff off by heart. My wife’s been looking at a draft of a GCSE Science syllabus tonight and it looks so content heavy and seems to require so much learning of oh so important facts and laws and equations. My own explorations into the new Computing National Curriculum (with it’s talk of von Neumann architecture in some of the “guidance” – more of that at a later date) have seen the same sort of thing.

Stone age curriculum. How fun…

Which is why I was Quite Interested in an article on the BBC website I caught today about how education has been going in Vietnam of all places. The ideas of developing a “deep understanding of core concepts and mastery of core skills” and “students [who] are expected to leave education not just able to recite what they have learned in class, but to apply those concepts and practices in unfamiliar contexts” seem strangely out of place against learning Newtons Laws by heart or attempting to understand the ways CPUs work.

And both so obvious and so alluring. And, you know, maybe actually fun.

There’s lots of talk of mastery around in our own curriculum of course. But I rather have the feeling that it’s being applied in a context which believes that it means “to know lots about” or “to be able to recite” rather than to have actually mastered a skill or even an idea. Sure, there will be some applied understanding questions on exam papers – but I know, from setting and marking real GCSEs, that these questions can easily turn into ones which reward blank knowledge.

I had a Year 9 child in the back my car this evening. A lift home from cricket. He was discussing with my son how he’d answered some questions on a science test they’d had today. “I knew it was something about that bit of what we’d been taught” he said. “So I just included as many of the key words as I could. Some of them are bound to be right and I’ll get the marks.”

And that’s where a knowledge based curriculum, rather then one which attempts real, deep mastery, gets you.

One of the problems with changing schools is that all the kit you’re used to having around (and knowing how it works!) stays when you go.

I, for example, am used to having a scanner attached to my work machine – and using it for all sorts of handy jobs, in particular scanning storyboards and other design work for my GCSE students. This is a Very Handy Thing to be able to just do.

But in my new school I (probably) won’t have that. Not to start with anyway.

At the same time, my old school had a bunch of old scanners still lurking around the place that won’t work with Windows 7, the standard network stuff. And there are a bunch of old, slow RM One machines that won’t really like the newer school network and are generally a bit out of date.

So – I wondered – can I solve my problem by using some out of date kit and, deep breath, installing Linux and then convincing it that it wanted to recognise the scanner? Well…

The Kit

This was all second hand, about to be thrown out, old kit bought before 2010 I imagine.

The RM One

RM Ones are machines with a screen built in. The ones we were throwing out were old single core processors with 1024 pixel wide screen resolution. Not the sort of thing that most of our up to date software would enjoy and generally a bit wheezy when running XP.

An armoured screen and compact footprint, however, make them ideal for sticking on a side bit of bench or desk and using when required. No CD or DVD drives, no floppy drive but plenty of pen drives. No WiFi. Nothing flashy, just a box with a built in screen.

The Scanner

An old Canon CanoScan N670U. No Win 7+ support at all (although I notice it would run on my Mac). I can’t even remember which room it used to live in, but it was in the pile of Stuff To Throw Away.

The Ubuntuisation

I started trying this at work but failed, despite creating a nice little bootable USB disk. Nothing occurred and it hung up after finding the USB and realising Linux was on the pen drive. And time got utterly chaotic at work and there just wasn’t time.

So, the machine went home and, on the first day of the holidays, I set about starting to solve the problem.

Firstly I downloaded an ISO of Ubuntu from the Ubuntu website. I went for a 32 bit install of Ubuntu 14.04 LTS, the most recent build of Ubuntu as far as I can tell. It’s called Trusty Tahr.

Then I swapped to my Windows machine and downloaded a copy of the Linux Live USB Creator. This appears to be needed to turn the pen drive and the ISO file into a form that is bootable from a machine restart. I followed the instructions and got the pen drive set up.

Then I tried it – inserted the pen drive, started the machine and… The same error: No default or UI configuration found. Darn.

Google…

The Solution

It seems that the pen drive I was using needed to be formatted to FAT 16 (or just FAT) standards. It was a 4 Gig drive and was using FAT 32.

The Installation

I just followed the standard installation process. Nothing got tweaked, just simple click to continue at each stage. Updating wasn’t ever going to be possible as the machine will likely never be connected to the internets. There didn’t appear to be a need to do anything odd or fancy. It liked the screen and set itself up perfectly well.

The Scanner (again)

So, machine working. I plugged the scanner in and – nothing happened. Tried pressing buttons on the scanner. Nothing.

Went to applications, opened the built in scanning software called Simple Scan. It opened. There was a Scan button. I pressed it. It scanned. Perfectly well.

The End Bit

So, it seems I’ve managed to convert an old, cranky and slow RM One into an offline scanning machine I can use in my new school. Other than having the pen drives formatted using the wrong baseline there really wasn’t a problem. I might need to download a few more piece of software for the box but, other than that, it looks like it’ll work.

So – think twice before throwing that old RM One out – or those old scanners. They can enjoy a new life – and one that only takes an hour or so of tinkering to achieve.

This came up in class yesterday so I thought a quick blog post might be a handy way of getting the key information online quickly.

Access report formatting can be awkward, particularly when you want to produce a letter or something interesting. Having fields from the database in separate boxes leads to nasty gaps and information getting cut off and so on. The solution is to get to grips with some of the more fancy formatting techniques.

These essentially use an Unbound Textbox to combine pieces of data. You need to use a new unbound textbox (not a label – make sure you pick the right icon!) from the top of the Design tab.

Because it’s an unbound textbox you have to start with =. Any text you want to add goes in quotes “Like this”. Any field from your data source goes in square brackets [likeThis] (you need to get the fieldname just right by the way).

You then link bits together using an ampersand (one of these: &).

So, an address for a letter might go:

="Dear " & [userTitle] & " " & [userSurname] & ","

Note the space in the middle. Any pure text I want to include goes in quotes – and there needs to be an ampersand between everything (if there’s not you’ll get an error thrown – check ampersands and quotes first when this happens).

You can also add longer unbound textboxes for the body of a letter – see te screenshot below. To do that though you might need to add paragraph breaks. These get a little tricky – look at the screenshot and I’ll explain what’s going on underneath.

Paragraph breaks get done using the & Chr(13) & Chr(10) & sequence. Check you have ampersands between everything.

This works by using Ascii code (google it…). Essentially every key on a keyboard has a numerical code associated with it. Some of the keys don’t print anything on the screen though – like the arrow keys or the return key. Chr(13) is a carriage return code – it moves the cursor back to the left hand side of the box. Chr(10) then adds a new line by moving the cursor down one line. Combining the two codes (with concatenation) has the effect of giving you a new line. Adding more than one set will give you a paragraph break.

Date formats – these can be changed within a report as well. The code to change a numeric date (like 25/02/2014) to a written date (like 25 February 2014) is shown in the screenshot. You might have to play around a little with this – don’t forget the round brackets – essentially Format$ is a function so needs round brackets.

a clear specification for the spreadsheet clearly identifying what’s required with a technical justification for the ways you’ve opted to approach this. This should link to objectives and success criteria – this is Part 1 – Specification

a working spreadsheet which produces all the outputs required. You might want to consider having this saved as a template (to allow reusability) and having a version saved as an unused sheet

screenshots (or PDF versions) of example outputs would be helpful – possibly annotated to show how you’ve covered the requirements of the specification

designs for each worksheet and user form used. These need to cover all the markgrid sections

probably some kind of discussion of how you’ve covered elements such as “user efficiency”, “accessibility”, “usability” and possibly aspects such as validation – these might not be immediately apparent from the spreadsheet itself. This will fit in with the technical documentation section of Part 7 – Documentation

testing evidence (see below)

If you can try to produce as much of this evidence as possible at this stage it will save an awful lot of time and effort in the future. Promise. In particular you might be able to cover a lot of the Documentation section at this point – the technical element of that anyway.

test prototypes – i.e. test your designs and test some rough versions to show that you’ve got feedback on what works and what doesn’t work. Screenshots would be helpful here – you need evidence that you got feedback and made changes as a result of that feedback

The element testing should test each individual possible input and process. So, for example, if I press a button then what should happen? You want to be clear about exactly what you’re testing and what should happen as a result. I’ll put more detail about this on the web soon.

Hopefully your detailed specification stuff is now done. Certainly you should have dealt with inputs, processes and outputs (and processes should probably include storage requirements as well). There may be odds and ends such as security that you want to add to that.

The job for today is probably to complete an Information Flow Diagram and then move on to objectives and, probably, success criteria.

The IFD certainly needs to make sure it includes all the inputs and outputs from the specification. It’d be a good idea to double check these against the exam board scenario stuff afterwards as well.

We spent some time noting that the consultant (Tracy) phones up the Admin Assistant (Derek). No data gets transferred automatically within the computer system – it’s done by phone. So:

the spreadsheet produces a list of all the products ordered (e.g. 4 bottles of vanishing cream)

the consultant rings up the admin assistant and dictates the list of products ordered over the phone

the admin assistant enters this into the database

the database produces a dispatch note

the order is picked and sent back with the dispatch note

Make sure this is in your IFD clearly – and then reflected in the objectives.

The database also needs to be able to:

store details of orders (but not customers)

have new product details entered into it

have new consultant details added to it (and, therefore, store consultant details)

produce dispatch notes

produce low stock reports

produce certificates

These need to be clear – and are obvious objectives.

Objectives:

The more detailed you make these the better. Probably. I don’t know how many you should end up with – I would imagine at least 15, quite possibly 20 or more. That’s OK – the more detail you have here the more obvious it is that you’ve broken the job down into sections.

We might end up adding some objectives in – things related to security or accessibility for example.

Success Criteria:

Each objective needs at least one success criteria. This should be a “can do” statement that I should be able to look at and say “yes, my system can do this”. If you have detailed objectives then you may find that you have only one success criteria per objective. If your objectives are a bit vaguer you may have multiple success criteria for some of them. That’s OK

Expect to come back to the success criteria at some point.

Next jobs:

Finish off all the specification stuff, including objectives and success criteria. I could probably use seeing information flow diagrams and perhaps objectives and success criteria.

At some point we need to come back to the Technical Justification section as well.

The aim is that by next Tuesday we can get on to actually designing the darned system…

We started by fixing the url problem the exam board had with their scenario web pages and quickly demonstrating what css is. That might come in handy for the e-portfolio stuff briefly.

Outputs:

Then we talked about the outputs that Dawn’s system needs. We decided that Tracy the Consultant would produce some outputs, probably at the party (hosted, if you remember, by Gwen) and using the Spreadsheet system. Derek the Admin assistant would also produce some outputs using the Database.

We talked briefly about how there was a link between Tracy and Derek – Tracy phoning in the orders (using the list) and Derek sending the completed orders back to Tracy (with a Dispatch Note in the package). We talked about what sorts of information would need to be on each of the outputs as well.

I think we decided that there were at least 6 outputs that were needed. I’m not going to list them here as there are marks for doing that sort of thing…

Advantages of ICT solutions:

I showed you some examples of invoices and receipts at this point. Some were nice, others were hand written – these will be linked on the internets once I get a chance. We did talk about some of the advantages of using an ICT solution for the sales receipt – points like readability, speed, reliability of calculations, ability to change prices quickly, consistency of style and branding for example. Some of these were good reasons to use a spreadsheet – these will be handy in the Technical Justification section of the specification.

Inputs:

Then we talked about the inputs needed into the system. Tracy will need to input some stuff. She’d certainly need to input the details of an individual order (say when Daisy orders the products she wants) and probably input a few other details as well – perhaps some personal details and maybe the details of the host etc…

Derek would then take Tracy’s phone call and she’ll be dictating the party order over the phone to him. He’ll need to input that in some way into the Database. He also needs to be able to input things like new products and new consultants details into the database.

Data flows:

I think I probably mentioned the data flows between the two systems again. It would be a really, really good idea to come up with an Information Flow Diagram at some point fairly soon. This is a good summary for the specification section and will help you envisage the system. I even showed you how to do this more easily using a Drawing Canvas in Word (and, while I think about it, it’s probably a good idea to use a fairly small font size for this btw…).