Open means Open data

The Open in our name means several things, but we think one of the most important is “Open Data”. Unlike other projects, we don’t want to restrict your use of event and group data with bad licensing terms or crippled API’s.

For example, we’ve seen one API that only provides the first line of a description then a link back to their site. We think this is a pathetic attempt to look open whilst also driving traffic back to them – we won’t pull that kind of cheap trick.

We’ve been rewriting our terms and our API help to try to make this clearer. Any feedback on what we could do to achieve this, or on what you want in an API is welcome.

We’re being careful to specify that our event and group data is open, but the data we hold on users is private and protected, for privacy reasons. We also currently use a closed data set to turn postcodes into latitudes and longitudes, so we have to be careful about that.

But we are very proud to say several sites already use our data – and we hope you can find a use for it to.

ps. If your not technical enough to consume our API yourself, we also have a widget you can just drop on your site and a display board you can use.

Getting bad feedback

After your event one of the problems is knowing how you did. I say problems, because this is actually a lot harder than you think.

The problem is simple – most people will not tell you directly if there is something they didn’t like. Instead they will keep it to themselves, or bitch to thier friends, or just not come back. And then you may think everything went great simply because you didn’t hear otherwise.

So firstly, go out of your way to hear bad feedback. Ask people regularly for feedback and always think about what you could improve.

And secondly, don’t boast about how well it went unless you are really sure. There is nothing worse that seeing an event organiser tweet about how they “nailed it” when you know a bunch of attendees went to the pub afterwards and complained about certain elements.

Of course, you may listen carefully to someone’s bad feedback and decide it isn’t relevant. Maybe they want something specific and you are aiming for a different type of event, for instance. How you deal with the feedback you get is a different issue. But always do your best to listen.

ps. And also, real listening often involves a long conversation to get to the real root of the problem and will probably bring up some complex issues with several subtleties. Twitter is not a suitable medium for this. Few electronic chats are. But that’s a topic for a different post.

We are going to be 1 year old soon!

On the 24th of July we will be one year old – check out our old launch announcement here!

We wanted to ask: what do you want us to do for our Birthday? Any special feature you want us to work on, or thing we should do? Comment below, get in touch or add it to our issue tracker.

And thanks for all your support, and thanks to Toshiba Medical Visualization Systems for the sponsorship. Here’s looking forwards to another year!

New feature: Display Board

If you work in an office and have a screen up showing vital stats to your staff, why not also have one showing the upcoming events in the local area to?

displayboard

You can configure each one differently – this one shows events in Edinburgh in normal colours, and events in Scotland in gray. You can also configure the number of days that appear in the middle box.

If you want to try it, get in touch and ask nicely!

Audience interaction and moderation

The topic of audience participation during a talk and the questions afterwards is a well argued one.

Some speakers welcome audience participation during talks. Some would rather talk first and then take questions at the end. It may be worth asking your speakers what they prefer and enforcing it.

Others would prefer the audience never ask questions as most of them don’t add anything. They say the audience can talk to the speaker afterwards. Well, some people will, but some won’t be able to find the speaker or will be to shy to go up and butt in on whatever the speaker is doing. And sometimes, listening in as someone else talks with the speaker can be really informative.

Some let people just shout questions, while some have questions submitted somehow and a moderator pre-approves them.

You’ll have to experiment and decide what works for your speaker and your community. (Personally, I’d happily ban questions during the talk but I think that the questions after can sometimes be the best bit.)

But whatever you do, it must be very well moderated. You need someone to set the tone, and who can then jump in and be strict if needed. The bigger your audience gets, the more important this and the suggestions that follow are.

If a meandering discussion starts that is off-topic or one person starts to dominate the discussion just politely but firmly kill it. “I’m sorry but that’s getting off-topic; why don’t we continue this discussion afterwards? Any other questions?”

If people are shouting questions, insist everyone puts their hand up and be strict about the order. This gives quiet people a chance to ask questions, and stops it becoming a free for all. Or if it’s a smaller event, say “Does anyone who hasn’t asked a question yet have one?” at some point.

Be clear about an end point at which people can leave without offending the speaker and those who choose to stay can start their own discussions.

If people are talking at the back, ask them to be quiet politely. Especially in an un-micced venue it will be hard for those around them to hear the speaker, so they are being selfish. (Also, this may be a sign that the session has gone on for to long.)

Generally speaking, this means the speaker can’t moderate their own talk. It’s possible but if your the one getting involved in a long drawn out ramble, it’s harder to gather the authority to stop it and move on. Also it’s good to have someone with an outside perspective who can see when the questions have gone on for to long.

Also, it’s a tiny courtesy, but I think the moderater has to make sure the audience are paying attention at the start. When you call for attention in a room, it might take a minute for everyone to sit down, finish the remark to their neighbour they were half way through and arrange their bags or whatever. Don’t make a speaker start over that and have to fight for the audiences attention – the moderator should do that for them. Just keep waffling an introduction for 30 seconds or so at the start until you are sure the audience is ready, and then pass over to the speaker.

The worst I’ve seen is one talk where they said strictly all questions had to come in over Twitter and a moderator would ask them during a final session. (So no questions over 140 characters then? Hmmm.) However after one question the organiser of the event started shouting questions from the audience. Because he had done so it gave everyone else a license to do so and before long a drunken guy was slurring rambled nonsense. The moderator said literally nothing after his opening question. I have no idea how it ended – I was one of a sizeable chuck of the audience who just walked out.

Audience interaction can be one of the best parts of an event if handled properly – experiment and see what works for you!

This is the one of several posts about running tech events taken from a talk I gave at OggCamp 2012. I’m not claiming this is the definitive guide on this matter,  but hopefully this will give people something to think about and start a conversation.

Supporting woman, non-whites and minorities in tech

There has been growing awareness recently about the abuse and problems woman, non-white and minorities face in tech, with some male bloggers joining in to say that those who stay silent on this issue need to take a stand.

We agree, and we want to go on record and say we recognise there is a problem with a lack of diversity in our industry.

We know there is a wide debate on what the best way of tackling this is and we don’t claim to know any of the answers. But we note more conferences are reaching out to under-represented speakers, running blind selection for speakers and adopting strict policies on attendee behaviour.

If there is anything Open Tech Calendar can do to help, suggestions are welcome in the comments below or privately.

New Feature (Curated Lists) is launched with start of new design

This morning we launched the start of work on our new design. There’s lots of details still to be sorted and lots of work we want to do that will improve the UX workflow but this is a first step, and we wanted to get it out there. This is a project that has always benefited from feedback and ideas from the community, and we are grateful for the advice we have already received – more is welcome!

Welcome to a redesign

We also launched a new feature that several people have been talking about recently: Curated Lists. These are lists that a user can create then pick and choose events from the site to add. They can build up a personal list of events on the same topic, in the same area or events they endorse.

You can then get a feed or a widget for your website that lets you display only entries from your curated list.

At the moment all lists are public. If lots of people ask we may think about private lists later but so far no-one has come up with a good use for them.

At the moment only the list owner can add events. In the future owners will be able to specify other user who can add events (UPDATE: now done), or specify that the list is open for all users to add events to.

We will also look at letting you add groups to your list to.

But that’s a lot of talk about features – wouldn’t it be great if there was an easier way to discuss all this?

In fact, something else we are starting is an open issue tracker on GitHub – this will hopefully make it even easier for the community to suggest ideas and feedback on what they want to see. Get stuck in and post suggestions there!

So again, all feeback is welcome by email or via our issue tracker or in person at an event – talk soon!

The importance of communication

When running a meetup, it’s important to establish a clear line of communication with the attendees and make sure that messages are sent regularly. You never know what attendees are listening to.

I learnt this when I was the main organiser of talks for Tech Meetup Edinburgh. One month I didn’t update the website with the speakers as I was very busy and to be honest, I didn’t think it mattered. I was soon corrected by someone who asked me what was happening that night, before politely but firmly pointing out the website was not updated. I could do nothing but apologise.

Every month I email events from Open Tech Calendar to a email list. Whilst normally I email events a couple of days before the month starts, on January 2013 I emailed it on the 4th. This was partly because of the New Year holiday – it won’t matter right? (It was also partly because there was a bug I was hoping to fix before I sent the email.) At a big meetup someone came up and said “I want to report a bug!”. Me sending the email several days late had meant he had missed an event. Again I could do nothing but apologise.

Recently I went to a meetup that was usually in a set pub. Several people had turned up, but not the main people. I asked the staff, and they were confused as several people had been asking after it and they hadn’t been told anything. They knew it was a usual booking, but this month they hadn’t heard anything. They asked me to get the organisers to call them.

The meetup’s own website did not list the latest events – it was two months out of date. Eventually I found someone on the phone who told me it was in a pub across town. Arriving late, I got chatting to one of the people sometimes involved in organising it who airily said “It’s all on Twitter”. That’s clearly wasn’t adequate.

(No names. I’m trying to make a general point, not have a go at anyone.)

Once you have established several clear communication channels, be they an email list or a webpage or anything else it’s important to stick to them. People are watching.

Annnnd this is the bit of the blog post where we start telling you how Open Tech Calendar can help with this problem. We know there is a lot for event organisers to do and they often do a under-appreciated job. We want to make life as easy as possible for them.

By adding your group and adding events in just one place, attendees can get an iCal feed to add to their personal calendar, a reminder email on the morning of the event or an email every time any details change. You can get a widget to place on as many websites as you want that displays the latest events from your group only.

And even better, our open Wiki design means anyone can add events. This way attendees can help out by editing entries and ensuring they are correct for organisers.

A lot of people check us to see what events are on, so give us a try!

Technical talks should introduce concepts

One of the things that I think is key to a good technical talk is to introduce concepts instead of getting bogged down in code details.

You see, most programmers are self taught. Which means that if they know something can be done and they want to do it, they’ll just sit down with Google search until they crack it.

So teach concepts instead. The idea will stick in the programmers mind and when they need it, maybe years later, it’ll pop up again.

For example, I found learning Android programming easier because I had seen a talk that explained the basic concepts of the activity life cycle and the intent system that sends messages between activities.

Or the talk about messaging systems that I saw was perfect for web developers. I think when I finally came to use a messaging system I used a different one from the one that was demoed (I used Beanstalkd and I can’t even remember for sure which one was demoed) but what was important is that the talk taught me a better way of moving the workload from the front of your web app to the back end.

So when I was finding talks for Tech Meetup, I would find talks like an introduction to user testing not because I thought all programmers should be experts in it (I wouldn’t call myself an expert) but because I thought every developer should at least know that it exists and the basic concepts.

I’m not saying you should never have any technical details in a talk; sometimes a technical detail or demo communicates the idea much more effectively than words ever will, and its usually more entertaining. But always remember to concentrate on the concept.

This is the first of several posts about running tech events taken from a talk I gave at OggCamp 2012. I’m not claiming I’m always right, but hopefully this will give people something to think about and start a conversation.

This is a repost from my personal blog,

More personalised services for attendees

Today we launch another tool to help event attendees stay organised – a personalised email on the morning of events they are interested in.

In your user profile you can change what triggers this email:

  • Turn the email off completely.
  • Choose to only be emailed when an event is on today you’ve said you would go to.
  • Choose to only be emailed when an event is on today you’ve said you would or may go to (the default).
  • Choose to only be emailed when an event is on today you’ve said you would or may go to, or is on in a group you follow.

todayEmail

Feedback welcome as always!