Category Learning

NOOT GUI: it’s all about affinity

Hooray! I finally got my GUI (for NOOT, my research minor project) ready and it’s turned out quite simple. See below.

The user starts with a blank page, then uses the menu to import a certain dataset. This set consists of images (crossed squares) and audio (circles). These show up on the page, in a grid. The user now can “work” the data, by dragging things together. Images can be expanded, audio can be played. Using the playback controls at the bottom, the whole audio set can be played back.

When the user hovers over a group of data, the title and labels assigned with this group become visible. Using these controls makes it possible to add meta-data to the groups, giving them more meaning.

Using the export option from the menu brings the user to another page, which is ready for printing. The page is filled with all the groups, using the boxed view up right, to display all available information in a structured grid.

Effective discussions

During the last few days I have gained some interesting insight in discussing. Last Thursday I observed people who were having a meeting, a brainstorm. They didn’t really come to a conclusion or resolution, because – in my opinion – all of them constantly defended their own piece of land.

So here goes, some infallible* rules for effective discussions.

Don’t do it
Perhaps the most effective action you can take to make a discussion effective is to avoid it. That seems contradictory, but let me explain. A discussion, in my opinion, is a conversation between people where certain opinions or views do oppose each other (or at least do not endorse fully). There is something to discuss, a necessity to come to some sort of an agreement. Apparently it is necessary, so you’ll have to do it. But how and why did it become a must? Because you didn’t agree with it in the first place. You started the discussion, because you wouldn’t agree. So agree!

People tend to see change as a problem. The problem needs to be solved, we don’t like change, so we bring it up in a discussion. We want the old situation back, the way it used to be. However, change is good. It means something is going on, it’s the natural way things go. Things never say the same. You can resist that, bend it, lobby, work your way around it – it won’t work.

So what do you do? Agree? Snap – just like that? Let them walk all over you? No, of course not. You just approach something you perceive as a problem as something else: an opportunity. If you can do nothing against it, go with it and use it to your own liking. Use the influence you have, not the influence you don’t have.

Steer with, not against
That said, you’ll probably end up in a discussion the way you used to do. But now you have a chance, a chance to change the discussion and its outcome to your liking. Not by steering against the current, but steering with the current. Seek within the subject of discussion for things that can help you further. This is an opportunity to act, to change and to have benefit. It seems contradictory, but when you look at it from this perspective: the more problems, the merrier.

By many people, wise and unwise, this has been described as a “win-win situation”. It is a circumstance where both sides can have benefit, together. Neither makes a concession, because that’s win-lose and lose-win. Which is basically lose-lose and nobody wants that. Making a situation mutually beneficial takes responsibility, the courage to look at a situation from the perspective of the opposite person. By understanding their side of the story, you can discover what their real goals are and you can support them with achieving it. They, on the other side, do the same. You both come to an agreement that suits you both and is for everybody of equal benefit. It sounds utopic, but it is fairly easy to ask “What do you mean” to somebody, isn’t it?

Be reasonable
There are problems you can’t solve and there are solutions you can’t accept. When that happens, try to look beyond the problem. What happens if this continues? Make a plan for that situation. Is the solution still unacceptable?

Always suggest a reasonable solution. The opposite side of the table won’t agree with less. They want their money and so do you. Being reasonable is key in this.

Also, note that being reasonable also means that you’ll eventually have to accept something you don’t like. But do you really dislike it? Is it really that bad? Relativize the solution. What happens when it really happens? Is the world still turning? No? Really not? It probably still is.

When the world stops turning
Abandon ship. Come to an agreement with one another that you simply don’t agree and will part as friends. It is useless to fight against a current too strong. You didn’t lose, you just couldn’t figure it out and will try another way. It’s worse to continue with a bad solution, than to abandon discussion if you can’t agree.

The asterisk *: if you don’t agree to what I’m saying, feel free to discuss it.

On “How To Live Before You Die”

I found this video very inspiring. Finding the things I love and doing those things is perhaps the single most important thing I want to do in my life.

I once made a list of things I wanted to do in the coming years. On top of the list was the most important thing: pursue happiness. Ever since I’ve tried so and this video encourages me to continue to do what I am doing to day. Because if you’re truly doing what you love, I believe you’ve truly found happiness.

The video is courtesy of Stanford University. The talk is by Steve Jobs, delivered on June 12, 2005. The text is right here.

How the heck did I learn programming?

I’d love to have a cup of coffee with my younger self, preferably around the age of fourteen. I tried some BASIC programming when I was younger, but you really can’t call that programming.

I want to ask myself a simple question: “How do you learn to program?” I really can’t remember the answer. Somewhere around those years I got a computer from a friend. I found a BASIC interpreter on it and got a book from the library about programming. In it were simple examples, which I tried. I’m pretty sure I didn’t understand any of it, but those days still were my first encounters with programming.

Two years later I was busy with websites. I made several websites with PHP, but nothing was quite like what I’m doing today. I had no idea what OOP or MVC was, but I remember I once got a nine out of ten for IT in secondary school because I managed to write a domain-lookup with PHP. At the age of seventeen I spent a lot of time writing a modification for Wolfenstein 3D (Command-F this page for “lwmxynedtodth”), my first experience with C. I should have been studying though, because I was graduating from athenaeum that year.

It al went fine. Right now, almost four years later I am working on a research project. On the side I am the assistant of a lecturer for five hours a week. I teach programming, like I once taught myself how to write programs. I have three weeks to explain all the basics (here and here, Dutch) of Flash ActionScript to Product Design and Engineering students with no experience with programming at all.

And it reminds me of myself. This is a first encounter with teaching and lecturing in front of a classroom, but it is also another first encounter with programming. I have great difficulty imagining how all this theory and practical appliances look from the view of an unexperienced programmer. How the heck did I learn myself programming?

About my research project

Last september 2010 I started the fourth and last year of my bachelor studies in the field of mediatechnology. My courses of choice were four IT classes, but I quit after six weeks because I didn’t find it very interesting.

I like to learn, but more from a practical point of view. When I unpack a new gadget, I don’t read the manual. I just start with trying to explore its abilities and read the manual later.

Right now, half a year and quite some freelance work later, I start with another research minor. This is user experience design, a course that is available as a specialized graduation “route”. Together with a PhD around here we planned a research project, which will keep me busy for the next five months.

Shortly, what I will be doing is designing a graphical user interface for a tool that is used within brainstorm sessions. The tool works well and is actually in use, but it lacks a proper GUI – you’ll have to start it on the command-line. The tool consists of several tangibles and an interface to record audio. The audio records during the session and the participants can place markers in this audio stream, e.g. when an interesting event or idea takes place. Markers can be played back with a tangible, an ear.

What I will be doing, is creating a GUI that enables participants to order, cluster and manipulate the markers they made in the brainstorm session. I’m thinking of an external web interface that can be accessed from their offices, days or weeks later, to get back to the markers they previously made.

I’m not entirely sure what the final result is going to be, mostly because the requirements aren’t really clear yet.

There’s a lot to find out and a lot to learn.

On “best efforts”

We all work together in groups, whether its for work, educational or personal projects. You all work towards one or several goals, which can only be achieved more or less with this group. You rely on others for their speciality and you try to be valuable yourself to help the group achieve what it set itself to.

Working in groups, professionaly and in my education, I have experienced several factors that limits the groups achievements. One of these lies within the very heart of each group: expectation. You expect a certain job to be done from a certain group member and after a while you discover that the certain person just didn’t do the job or didn’t do it properly.

In the past, when this sort of event occurred, I simply asked of the group member to do it again. Sometimes I would help them with it, or when it all went south I just did it my way myself. This usually resulted in a lot of stress, frustration and probably a worse result in the end. I emphasize “my way”, because I am well-aware that delegating a job is as important as delegating it to the right person. If somebody doesn’t “own” a task, they won’t feel responsible for it and then they won’t do it or do it badly. However, the inability to delegate tasks is beyond this short essay.

At a time I figured that this wasn’t the correct way to deal with it. It was a good way, but not the most succesful. At first I thought I was handing the wrong jobs to the wrong people. Trying to improve that made things go better, but it was not a real improvement. By handing the jobs differently, I wasn’t using the group’s capabilities to the fullest.

Then I realized that within each group, within each person of that group, lies a very complicated set of goals. A group doesn’t have one goal, it has several goals on several levels within several persons.

Consider yourself working on a major piece of software, that has to be released in the next product launch. You’re on the clock, you have ten features to build and you have five developers to do it. Four of five are doing great, but one seems to struggle with the easiest bugs and features.

You anticipate and assign part of his jobs to other developers. This causes stress for the others of your team and the bad-performing developer feels bad, because he’s not performing well. However, you think job well done and the management congratulates you on your success: with your management skill you got the product to launch in time.

Unfortunately, the bad-performing developer resigns next day. In his personal life he was having trouble with the relationship with his partner, and they separated. The stress in his work caused all this and his fading relationship made him perform even worse, which eventually led to their separation.

Three months later the developer is working for your competitor. He’s doing fine again. Although you won the short term, you turned out to be the loser in the long run.

I’m not saying you should get involved in the personal lives of your group members. In this case, it would have done well though. Apparently, this developer had one correlated goal aside his professional goals: maintaining a relationship.

In a group, expect people to do their jobs to their best effort. That’s all. Do not only look to their competences and skills, find out why they do what they do and what motivates them to do it. All work starts with motivation, which mostly derives from liking or interest. If you understand what the individual goals are of your group members, you can possibly perceive what the best goal for this group is.

You cannot change people, but you can change your goals. Trying to make your goals is not about getting to them, its about setting them correctly. I am well aware of the fact that this can turn your group into a tea blending party – so be it. If your group is very capable of blending tea, they should make tea blends.

But most likely your group is good at what they’re doing, with a few exceptions. Find those exceptions and find out if they are grounded in bad expectations, they probably are. Try to figure out better places for these people, or better circumstances. Try to find out what the individual goals of your group members are and try to help them to achieve those goals. Only like that you get real cohesion in a group, all aiming for individual goals to achieve the goal you’re all having.