Divide and conquer Twitter

I’ve used Twitter now for over 3 years (a late starter, making up for that now) but in all that time have never made use of its list functionality. I hate the way Twitter forces you to click , click, click and click again to add a single user to a list and then wait for you to close a window before continuing with the next user… and the next… so, up until now, I’ve made use of hashtags and browsing the main timeline. Not very efficient.

In contrast I really like the way Google+ allows you to build your circles without fuss using drag and drop. I hoped someone out there had created something for Twitter lists that worked in the same way, searched Google for a while and found Icotile (http://icotile.ogaoga.org/, free).


As you can see the main part of the interface is made up of small tiled images of your Twitter contacts. On the left hand side of the screen are the lists you have created and on the right is the biography of currently selected Twitter user (very handy!). To add a contact to a group simply drag the image on to the list.

It’s not perfect – I’d love to be able to select multiple contacts before adding them to the list for example. You should also ensure you have created all the lists before starting to use Icotile to avoid problems when adding (it doesn’t show any error messages should a contact already be in a list or cannot be added to one). I also think that being able to filter out contacts already added to a list would be very useful, especially when you have over 1500 to sift through! However Icotile has allowed me to begin to organise my Twitter streams more efficiently and allow me to customise my Chrome TweetDeck app (free) to show selected lists rather than the timeline and a series of hashtag searches.


Can anyone suggest alternative ways of organising your Twitter lists?

Notes on a failed lesson

DIY Board Game by San Jose Library, CC BY-SA 2.0 http://www.flickr.com/photos/sanjoselibrary/4788007123/sizes/m/in/photostream/
DIY Board Game by San Jose Library, CC BY-SA 2.0 http://www.flickr.com/photos/sanjoselibrary/4788007123/sizes/m/in/photostream/


At the very start of this session I used the idea of simple games to get to know my Higher Computing class and clearly define the importance of rules, structure and boundaries when problem solving. They had the option to play War, Shove Ha’penny or Penny Football and learn how to win (or at least how to avoid defeat). My class were well motivated by the opportunity to spend around 80 minutes exploring, in some cases, these >new< games! The intended outcome, relating to computer programming, seemed to be an easy step for them and I noted that the students, having spent the time playing those games, were able (in the main) to use them as a reference during the remainder of the unit. So far, so good.

In the next unit I returned to the games analogy when tackling the Fetch, Execute cycle (which relates to the internal workings of a computer processor). Instead of having the Higher Computing class play simple games which relate to the need for boundaries I gave the class the boundaries and rules involved and set them the task of coming up with their own paper-based game to reinforce the intricacies of the Fetch, Execute cycle. I asked the students to create rather than consume and hoped that the freedom I gave them to come up with their own ideas (in groups) would result in some interesting interpretations. It did, but not as I’d hoped.

I made a few big mistakes:

Firstly, the subject matter may have been a bad choice for this kind of task. Higher Computing exams tend to require regurgitation of the Fetch, Execute cycle steps – there is no scope for scenario-based problem solving here – so it’s all a bit too abstract really I suppose. In the past I’ve employed other kinaesthetic methods for teaching this – usually involving bouncy balls or whiteboard pens being passed around the class and ending up being aimed at a target (a clean metal bin is perfect for this and gives reassuring auditory feedback). Each student had a role to play in the transfer of data from one part of the room to another. A major drawback was (I felt) that they were consuming another game and perhaps not engaging with the subject matter as deeply as they could – hence the change this year.

Secondly, I hadn’t asked the class to create a paper-based game for me before. I hadn’t modelled it either. Really daft when you think about it actually and I’ve already identified a few opportunities to introduce paper-based game creation during the programming unit for next session.

The resulting game ideas (no group finished their game in the allotted 80 minutes, although they were all keen to continue creation for the rest of the week!) all had one thing in common. None of them related to the Fetch, Execute cycle at all! The students had concentrated on the game mechanisms before thinking about how they were going to reinforce the subject matter. After “letting go” and listening to (and attempting to guide them a little in)  their discussions I knew about 40 minutes in that they were going about it the wrong way however I held on to the hope that they would suddenly “get it” and produce the goods. You already know that this didn’t happen and I ended up looking at a deck of cards, monopoly board and snakes and ladders board. No group had any inkling how they were going to create a structure for their game.

The intended outcomes of the lesson were to be able to correctly sequence the Fetch, Execute read and write cycles and use the correct terminology when doing so. However by diverting the focus from the content to the means of delivery I undoubtedly failed the class that Monday morning.

So I spent the next two hours of non-contact time creating my own example game (which, in retrospect I should have done anyway!) that mimicked the process of the Fetch, Execute cycle and forced the players to use the terms and sequences to make progress. I tested the finished game out with some of the students later in the week and, although it had a few flaws, I feel they learned about the subject matter. This was what I really wanted from the class in the first place, but I also wanted them to engage more deeply by creating their own resources. I wanted them to create rather than consume. Next time I’ll remember that if I want students to change, they need help and mentoring to do so.