Wednesday, January 23, 2013

Walk the line : The hard way of the negative feedback

Today I was confronted heavily on many aspects of some tools (which I will mention as "ToolX") I have implemented. I will put this as "feedback" as calling it "critics" is limiting (it was not all disruptive but also constructive).

Anyway; the sense of it is simple : getting feedback is easy; taking it is hard.
The first reaction to feedback is usually very well described by the following situation:
You sit at work, a co-worker comes up to you.
"Hey xx, I have a problem with tool xx. It does not do it's job."
I am pretty sure that this situation hits (or has hitted) alot of us.
Out of the frequency this event happens, you can give a score to the value of your work. This is why it is important to not just say the following :
"What? Impossible, my tool xx is awesome and works!"
 "You must have used it wrong!"

 Which, translated into practical sense, equals to NOT listening.
 An answer like the following:

"What is the issue?"
"What's the matter?"
would probably be more appropriated.
So this seems easy so far - unless you have attitude problems (like myself); but then it's bad luck and failure until you learn your lesson (which might take some time, I tell you).

So, assuming your colleague did not run away chasen by you, the next thing you will have to figure out what is wrong with ToolX. Is it working? Yes/No? If no, what is the cause? Your colleagues wrong usage of the tool? a bug in it? environmental conditions (for example file shares offline...)?
In the end, alot of issues to go through. Assuming there was actually an issue - either in the user's usage or in the tool / environment required by the tool to run, the result might be :
"Ah, I did not know I had to do it like this"
"Ah, there is a bug!"
"F*ck, why is this server offline?"
Anyway, the outcome can be various.Usually if a bug is found, a discussion about the tool might emerge, and if the galaxy stars happen to be in the right configuration, you might be as well as lucky as being able to collect some feedback on ToolX. The form of this collection is purely passive; meaning the User will give a (usually oral) list of issues that he / she has encountered during his/her life making use of ToolX. See, here is the first challenge: Organizing feedback transfer. But let's not focus about that, there is plenty of documentation on the topic already.
What I want to focus on, is the magic moments of the conversation in which you will get negative feedback on ToolX. Why? It is easier to put it in a metaphor:
a feedback collection (from your point of view) is a race that your tool is being putted into, to evaluate it's performance. If the tool fails to achieve the race's goal (which it probably already did, for an example in the situation given above) or completes the race poorly (which means the User's list of bad feedback is LONG), your tool is most likely not up to the task
This reality might hit you; but also, you might not even hear it, because your self-protection mechanism will automatically switch the areas in charge of common sense of the brain off.
So the reaction can be two fold, either you listen and do not take action (because you did not really listen to the feedback), which I will herein call SCENARIO#1, or you take the reality: you have a shitty tool and do something about it, which is SCENARIO#2.

So far for the consequences. But how to be able to decide which of the two abovementioned outcomes to go? In the case of SCENARIO#1, you are obviously not in control of yourself anymore (at least not directly), because you will simply ignore the input from the User. Do not get me wrong, you will still hear it; but it will go through your ear (in through one and out from the other) like air.

The solution is being able to recognize when your brain shuts down.

Whenever you get feedback, ask yourself:

- how many questions about the feedback have I asked?
- how many valid feedback points (out of the ones mentioned by the User) have I collected?
- how much chance for feedback have I given to the User?

I think the most tricky being the third one:
Usually, on negative feedback we react with defensive walls or "counterattacks" like
"No you did it wrong" 
"No the server was down" 
or even
"You do not know what you are talking about" 
and on.

The more of these whe shout out, the less feedback we have collected, the more we are sliding in SCENARIO#1.

Any of these "counterattack" reduce the chances of feedback for the User, for various reasons.
It makes absolutely sense to let the User speak. Even if his thoughts are nonsense, let the User speak.
You can decide later on what to do with it (provided you remember it).

I think this could be a good reminder for myself. Feel free to use it for you too, if you think it might help :).

Friday, January 18, 2013

LinkStation ROCKS!

So it happens I am starting to have some code laying around.
On my laptop. From 2007. Commercial code.
So I figured it is time to get a decent safety solution.
At work, we used this LinkStation Duo (or something) from Buffalo.
I was quite impressed, because once you get into it, it is almost a fully-fledged linux system.
So yeah, armed with the good experience earned on the LinkStation Duo I decided to go for a similar box,
and was lucky enough to hear from a colleague that he was selling this LinkStation LS-WXL.
I did not miss the chance, picked it up, brought it home, installed it, and worked my way into it.
It took some time, but thanks to the good articles over @ Buffalo NAS-central it was more or less straightforward.
So, I have hot source, and need a place to store it. Did I say SVN?
Piece of cake!
By following this link now I have a fully-fledged NAS running SVN :). Worktime? 1 hour! :)

Monday, January 14, 2013

N9 Apps for everyone!

Let me showcase you my N9 apps here!

BWizz is a simple and efficient browser bookmark editing tool! Export, edit, delete bookmarks of Firefox, Opera and the N9 inbuilt browser!
LINKer transforms your home view in a full desktop! SHARE from any SHARE-enabled application documents, images, bookmarks (for example Spotify URI's) directly to your homeview and access them with one click!

Saturday, January 12, 2013

Supersize QT - > QT + BB10 = Awesome - kindof...

Hell yes.
So finally a new QT phone. I mean, a phone with *official* QT support  (that is available, that is - as we know, Android and WP will be supported thanks to Digia in the coming future too, and also Android is already supported unofficially via the Necessitas). This rocks. This is multiplatformness in it's purest form.
In it's perfect form! It's a perfect world! I build an application for one device (say, the only 100% swype-certified phone currently in existance, the N9 / N950) and then require *minimal* changes to my app's codebase in order for it to run on other OS'es like, for an example, Black Berry 10 (BB10). Well, not counting the few changes to support the few differences in the APIs but apart of these, there should be nothing else that would require anything more, there...Because we do not WANT to have to change OTHER stuff, right? What we want, is to maximize monetization, by minimizing costs, no?
Well, f*ck that.
I think that is what is in the minds of most of the project planners of today's new OS'esses.
Why is that? Well, we have this nice and fancy UI scripting language which QT has introduced some time ago. QML, that's right. Now the C++ QT interfaces are standard. And you can't really benefit from them unless you use them; this architects seem to have understood. But the syndrom of NIH (=Not Invented Here) strikes back yet again in QML!
BB10 supports QT Quick components (sort of). But also defines their own set of QML components: Cascades. Worst of it, they are completely incompatible. So you not only have an extremely limited support for the QtQuick components in the SDK. I am talking of out-of-the-box usage of components mind you, aka bundled in the SDK, aka I want to use a Button class from my QML file in my BB10 QT project, and it works out of the box when I press "Run" on the first time! I know now people will think "why don't you just include the ones from the Qt SDK" and on, but the heck, who wants to do it? Who takes the time? Qt is supposed to be officialy supported by BB10! OFFICIALLY goddammit! Why use that word if it is NOT true? So I was saying, on top of this, not only you get an SDK with limited support of QT's QtQuick QML, but you also get incompatibility between the QML components defined by Cascade versus the QtQuick ones! How's that? Well, check this out.

The following is an example of an out-of-the-box "QtQuick project for BlackBerry" from QtCreator 2.6.0:

#include <QApplication>
#include "qmlapplicationviewer.h"

int main(int argc, char *argv[])
QScopedPointer<QApplication> app(createApplication(argc, argv));

QmlApplicationViewer viewer;
viewer.addImportPath(QLatin1String("modules")); // ADDIMPORTPATH
viewer.setOrientation(QmlApplicationViewer::ScreenOrientationAuto); // ORIENTATION
viewer.setMainQmlFile(QLatin1String("qml/main.qml")); // MAINQML

return app->exec();

Nothing special, we have our usual qmlapplicationviewer.h and stuff.

Now, the same for Cascades QML, please:

#include <bb/cascades/AbstractPane>
#include <bb/cascades/QmlDocument>
#include "myobject.h"
using namespace bb::cascades;

int main(int argc, char *argv[])
Application app(argc, argv);
//! [0]
// Load the UI description from main.qml
QmlDocument *qml = QmlDocument::create("asset:///qml/main.qml").parent(&app);
// Make the PizzeriaSearcher object available to the UI as context property
qml->setContextProperty("_someobject", new MyObject(&app));
//! [0]
// Create the application scene
AbstractPane *appPage = qml->createRootObject<AbstractPane>();
return Application::exec();

Can you spot the differences? Cause I can; and I tell you, this is *not* portable code. No SIR!
The main one is QmlDocument from BB10 Vs QmlApplicationViewer in QtQuick.

NIH wins again it seems.