Finally OutSystems has released a free version of its’ flagship product, and the response for it has been nothing short of amazing! This is what I’ve been involved in for the past months. It is called the OutSystems Express Edition, and it is still in beta stage.

The official announcement was made in a public event that OutSystems hosted last week, and from then on we have been receiving a steady income of considerable registration requests for the beta program per day!

While some people who might be unfamiliar with the technology might not understand what the fuss is all about, let me shed a little light on the subject.

At OutSystems we have always been a bit closed about our technology and resources. To download our development environment – the OutSystems Service Studio – you used to have to register in our site. Granted, the registration was free, but we required it so we could better keep track of our user base.

To download the platform where the applications would run on – the now called OutSystems Service Center – you had to be either a partner, a customer, or someone developing a project for one of those two.

Access to our “public” forums – as well as to our knowledge base – also required user login.

As of past week all of this became simpler.

The public forums and our knowledge base have become readable to anyone who wishes. You’ll only need to log in to post something in our forums.

The OutSystems Express Edition is a package that will set up the OutSystems Service Center and the OutSystems Service Studio in a user’s PC, along with the OutSystems Integration Studio and a full-blown open web application called OutSystems IT Asset Manager, which keeps an inventory of all assets in a network. For now, only those who have been eligible to participate in the beta program will be able to download it and start tinkering with it, but the bottom line is that you no longer have to be a customer to have access to our technology. As far as we know, you might be someone who was just looking for a free application that did what our OutSystems IT Asset Manager did, a freelancer doing projects in our technology for a living, or just someone who was just curious and decided to try out our product. Honestly: whatever gets you through the day will also get us through it as well!

I am really proud of being part of this great team. For long we have tried to find a way to bring our technology to a broader audience, so more people can benefit from it, and finally all our efforts have paid. I have already installed it in this laptop and it is a startling difference to actually play the role of the user of our product. For all of us who have been developing it and rarely using it for serious stuff, it just doesn’t get any more compelling than this!

As of this day, the first lucky beta users have been notified that the download is available, and in the following days more people will have access to the download link. If you are interested in enrolling in the beta program, register in http://express.outsystems.net and we’ll get in touch with you!

Cheers!

Earlier today I was listening to a talk from Guy Kawasaki on pitching – making presentations, getting your idea across, etc. In this particular scenario, he focuses on pitching to VCs and investors, but I feel that if your presentation is good enough for VCs and investors, then it surely will be good enough for most of the other audiences.

Even though the audio file is over an year old now, this is still a topic that most of us will eventually have to face so for those who haven’t listened to it yet, here’s the link:

http://blog.guykawasaki.com/2006/02/the_art_of_pitc.html

Cheers.

Still, this evening’s post is about the time I worked on “sexying up” a WYSIWYG editor. It was a noble cause – one I referred to previously when I talked about the importance of starting. I should have known better in the first place, but no – I dared to question and propose a change to the way this editor had always looked and felt like.

For weeks all went well, team morale was great and the development was being done at a steady rate. Ideas came, prototypes were made, tests were done, you’re familiar with the routine. When the project started to get close to the deadline, things suddenly had to take an unexpected turn. Due to technical limitations, I was facing a dillema. On one side we had a slick looking interface, which was hampered by a few quirks: the result of countless weeks of hard-work, powered by coffee, cookies and Dilbert strips… On the other  one there was a good enough interface, which had some nuisances that date so far back that are probably documented in the Old Testament – and as such, people grew up with them and have adjusted themselves to them. It was like using windows 95: after experiencing 10 BSODs, people started taking it for a feature.

Still, some users had already been using this slick version, and they were quite fond of the change. The problem was that they were not immediately aware that some of the quirks they were experience were not present in the previous version. They had been introduced by this change – and were not mendable easily (believe me, we’ve tried). They still didn’t care, they didn’t want to see! Only after some sense-slapping were they able to admit that those problems were real.

I can’t blame them, honest: it was like we had presented them to supermodels, had put them to date them for a couple of weeks, and now we were telling them “sorry, you’ll be better off making up with the ex-girlfriends/boyfriends you ditched for these, ’cause these are history”. It was the ogre’s choice, and I wasn’t proud of it. At first, the feeling that pervade my spirit was that countless weeks of work had lead to nothing and we were back to the drawing board – Wyle E. Coyote style.

The truth was that these sexier changes hampered the operations in the editor. Though it was more immediate to the user in many cases, in some scenarios it would take the user a bit more of effort to do normal things such as placing things on screen. This would ultimately lead to frustration, since this didn’t happen in the previous version of the editor, and these few occurences actually accounted for 40% of the regular user’s use cases.

The ultimate decision was to tag the code as it was right now – for future reference, -  revert the look and feel to the original one, keep the fixes made along the way and now start fixing things that could improve user satisfaction with this codebase. It was not what we wanted, but it was probably the best solution at that stage.

What I learned first hand from this is that no matter how similar the end result is to the starting point, the whole trip makes up for it. There will no longer be careless remarks such as “Ha, how come no one has thought of this first?” and “Why didn’t they do it like this then?”. Now I’ll be the living incarnation of the “Why”s of this whole project - especially the “Why”s that justify the “Don’t”s. And that is saying a lot.

Also, I was hugely surprised to see users sticking up for the sexier – but ultimately hampered – solution, and sad to go back to the old not-so-hampered-yet-sexy-as-a-goat solution. From a developer’s point of view – and myself as an user (albeit an over-informed one) – that still doesn’t make sense, and I sincerely hope it was just an initial reaction. I’m planning on keeping an eye on this particular topic, and getting feedback from users after this reverted-with-slight-improvements version is released.

Cheers.

It was actually quite provocative – as they usually are – and it makes for a very interesting read if you haven’t been there before. One of the most intriguing concepts it brings up is that “crowd” here is not a committee, nor a panel of experts. It is, instead, a set of individuals – individually.

Remember physics class? I remember them quite vividly. I remember that every test result I’d get to would only be true if the environment of the experiment was a perfect vacuum. The same happens with feedback gathering and decision making.

If you are looking to gather valid feedback on a problem of any sort from various people during the design stage of a product, the worst thing you can do is to gather a crowd around and try to get it all at once. As soon as someone starts talking, it’s like lighting the fuse for a bomb. In a matter of minutes the feedback fountain will have dried up, and you’ll be left with converging opinions – or maybe strong supporters of different opinions who weren’t able to settle on a certain point. And that’s what you’ll have to work on.

This kind of approach has the following drawbacks:

• What you’ll frequently get is a standardized opinion: not the solution that everyone wished for, but the one that fewer people disagreed on. While sometimes this “good enough” solution is actually what you are looking for, if you are looking for a more daring solution, you might want to keep away from getting feedback from a crowd at first.
• You’ll rarely be able to gather information about the “idea incubation” stage. During that process, every person’s mind was a different sandbox that was frequently being fed new information as soon as someone else said something that seemed useful. They would process it, and afterwards blurt out another idea, which will in turn be someone else’s idea-fodder.
• Usually, you will not be able to gather new useful feedback from these people after the first interview because they will have their minds set on a particular solution. Since the different opinions have converged (that is, the distinct feedback count is lower than the group head count), people will more frequently reason their way into “the group feedback was the optimal feedback” instead of thinking their way through it by themselves. Unless these people are as committed to achieving the best solution for your problem as you are, the effort of clearing their mindset to have another go at the same problem is an extra mile that few are willing – and able – to go, no matter how well-intentioned they are.

Though this kind of session is great if you’re on a tight deadline or reviewing a proposed solution – for which you are ready to back all the design decisions with valid arguments as well as open to question them if pertinent – the truth is that for a design phase it’s best to gather feedback individually, in the “vacuum”. This way:

• The fact that you asked each person individually will most likely get her more involved with the problem at stake. She’ll feel that you value her opinion enough to listen to her individually, and as such she’ll feel more compelled to help you out. 
• Everything you’ll gather will be – for the great majority – completely uninfluenced. As such, if you gather similar feedback, it will be because it makes more sense for each person, instead of having more people settling for a suggestion without thinking their way through any other.
• You will be able to gather the whole “idea incubation” stage as feedback. The more you ask the other person to think through the ideas out loud, more insight you’ll get on what a particular statement is based on. When time comes for you to question conflicting ideas, you will have more arguments to back each of them, and whatever decision you end up taking, you’ll most likely be more informed to make it than if you had just gathered the final result of the think loop.
• Since everyone has a distinct opinion and individual arguments, it will be more easier for you to question previous assumptions with the correct people, and “milk” every single idea as much as you can.

I’ve been trying this approach for a while now, and it has been giving good results. Sure, it requires more time and effort in the beginning, but I believe that it is worth it in the long run.

While this may be for some a time of pressure, I actually find it quite motivating. On one hand, the evaluation “season” makes for a great reason to retrospect on the past year: things that were accomplished, things that could’ve gone better, what you learned, what you taught… I always get that “Oh, that’s right! It WAS this year that I worked in the <insert project of choice here>” feeling, and it helps you sometimes see how much – or how little – you’ve changed, as a professional and as a person.

Still, there’s a task which I always feel a bit unconfortable doing, which is the peer evaluation. I believe that if you’re going to point out things for someone to improve you might just do it in a constructive way. This way, the one being evaluated feels not so much as being pointed out for doing something not as well as it should, but more as being told that he has the potential of doing something better, and that we are counting on him because we know that he is not doing things that way on purpose and that we know that he can do better. It’s a shift from “you’re not doing things as we expected” towards something more like “you’re not doing things the way that we are confident that you know how… And if you don’t know – or if it turns out that you can’t make it as well as we expect yet – you can count on us to help you in whatever we can”.

Though I feel this works great, there’s a problem: for each thing to improve, I write circa two sentences – one for pointing out what could be improved, and then one or two about things that could help improve. Imagine that I have 3 points for a person to improve – that’s a whole 6 sentence paragraph! Now, since I do NOT detail the person’s merits – so it won’t risk coming out as flattery, which is not useful at all - just pointing them out (“good technical skills”, “great team player”, “best taste in screen-savers”, etc.) ends up with evaluations that, text-length-wise, are 20% merits, 80% points to be improved, even though it might be the case where the quantity of merits surpasses the quantity of things to be improved.

No matter how you try to shake it, if you get an evaluation like this, after reading the whole text all you’ll be able to see is 2 lines for praise, and 8 lines for criticism. Your mind will keep seeing “so little praise, so much criticism”.

Well, I haven’t settled for a solution yet, but if things go wrong with this type of text, next year I think I might try something different: constructive praise and blatant-flat-out-destructive criticism (without elaborating).

 No one will ever complaint about this year’s apparent 20% praise/80% criticism ratio again after that.

Still, I decided to write on something that happened to me in a previous project I worked on.

The project

I was working on a small development project at the time, with a small team. Our goal was to deliver a template web application that could easily be re-used by power users for developing business web applications, yet was simple enough for any new user to pick up and try without feeling overwhelmed by it. This small project was part of a bigger project and as soon as this small project was finished, we’d both have other things to do in the master plan.

As such, this project was slated to be released “as soon as it could” but also “whenever it would satisfy the user requirements”. This meant that, even though the version had a strict deadline, this particular project didn’t have one at start – it should be released by the version release date, but preferably before. Since part of the project would consist of gathering an accurate requirement list, it would be up to us to assess what features and requirements would need to be fulfilled in order for the application to be in a deliverable state.

After gathering the initial requirement list, an estimated deadline was proposed, and we started working. After a first couple of weeks into the project, we had the chance of having some beta users willing to develop an application based on our template.

The reviews

As it turned out, this first version we were aiming for was overly complex to re-use. There were too many things one needed to change, and most of the screens were so over-complete they were like giant Swiss-army knives: some of the template content was bound to be deleted depending on the specificity of the final screen. Oh, and God forbid someone wanting to create something that would deviate a bit more from any of the existing screen templates! It was something comparable to the experience of tightening a screw with a ballpoint pen.

Back to the drawing board we went, and this time, we simplified things the best we could. We even removed some of the initial restrictions and assumptions in the name of simplicity. It was not without its’ flaws, but it was better than before. Sure enough, this step backwards was not in our initial budget, so the budget stretched a bit. It would mean that we wouldn’t be able to join other projects on the initially planned date, but it was needed, and we were on track again.

Weeks later, on a second user review, we were pointed out that, even though it seemed simple enough (from a regular user’s point of view) to use and re-use, the fact was that almost no one would be able to use the templates without needing to customize them: even though we had a generic data retrieve and list page, for instance, some users would need page navigation through the data, others would want filters to reduce the search scope, while a few would like to able to sort the data. These were all valid reasons – we were trying to provide templates so that other developers would not need to create these things from scratch.

No size fits all

Another slight budget re-adjustment and a couple of weeks later we were closing in on the deadline. The ever-increasing backlog now consisted of bug fixes, simplifications we could still apply to some screens, and a couple of problems that kept being pointed out by the users. The main problem was that power users demanded more variety and composition of screen templates (such as a screen with an input form followed by a data list, for example), though each user had specific needs for different compositions, while other users were already defending that the application consisted of way too many different screen templates, that they would not use half of them.

Both sides were true, and had valid arguments. We could not settle for any of them without harming the other party, and we were not keen on adjusting the budget once more. As such, we stuck to the deadline: we committed on a requirement set that needed to be fulfilled, we fixed the bugs as best as we could, we stabilized the code so that – should something bad happen – we’d have something to deliver on time, and until the closing date we added one or more small features – mostly cosmetic or trimming edges – to the application that would add value without compromising it’s stability.

And that was it. Sure, the application wasn’t perfect. It was definitely not the “one size fits all” we had imagined at the beginning, but it was good enough for some purposes. More importantly, though, the fact that it was released meant that the application was now public, and more users could use it to help them develop their own applications. And while they were at it, we could actually gather more feedback that’ll help us decide what to include in subsequent versions. It was a win-win situation – even if it was not a resounding win for either side.

If we had not done that, we’d kept going on week after week adding features that would never end, and we would have settled on an up-to-date requirement list by fatigue – or had just become another Duke Nukem Forever-like project.

Conclusion

As I’m sure most of you already know this from experience, the “deliverable state” of a project is almost never objective. Parkinson’s Law- work expands so as to fill the time available for its completion – is a well known reality in every development project, be it because of unexpected difficulties, ever-increasing requirements, an Utopian strive for 100% perfection, or any other reason you might think of. And one way to minimize it is actually to be able to judge when to stick to and when to increase the project’s budget – provided that that’s an option.

Bear in mind, though, that I’m not defending that you should not push the deadline once more if the project’s result is broken, or clearly incomplete! It is never too late in a project to correct a bad decision, no matter how much time it will take and how early in the project it was decided. What I’m saying is that if the product is in a state that already fulfills the requirements, and that the product as it is will already solve some problems for the users, then odds are that you are better off releasing it, instead of postponing it ad eternum. Face it: the backlog will never stop increasing – unless no one is using the product. From bug reports to feature requests, you’ll have a lifetime of product management ahead. And you can always – and should – release those bug fixes and feature enhancements in new product versions, especially if there’s perceived added value in them.

P.S. – I’m pretty sure I’ve oversimplified some of the topics I used to fundament my arguments, and I’m aware that I may have seemed naïvely optimistic in some cases, namely the “win-win situation” description for our particular scenario. There are some other fundamental aspects such as the importance of the product’s first impression on the user; I purposedly disregarded them for the sake of making a point on limiting the project’s scope in order to keep on track with a deadline, as I feel they’ll only add complexity and not that much insight. I’ll dedicate a future post to the impact that a first impression has on a product’s – and company’s – image.

P.P.S. – Recently I read a couple of articles on simplicity, and on the fact that our initial approaches to the problem focused either on flexibility or on simplicity. We were only able to start seeking both after a couple of user reviews.

About a month ago I was catching up with the blogs and sites I usually follow, and I stumbled on this great quote from W. H. Murray in Merlin Mann’s 43 folders web site:

Concerning all acts of initiative (and creation), there is one elementary truth the ignorance of which kills countless ideas and splendid plans: that the moment one definitely commits oneself, then providence moves too. A whole stream of events issues from the decision, raising in one’s favor all manner of unforeseen incidents, meetings and material assistance, which no man could have dreamt would have come his way.

I read it with a slight disbelief, yet end up feeling of strangely motivated. I mean, sure we all have had one of those moments where fortune/fate/karma/whatever you call it just unrolled a red carpet right in front of you, waving in your face just the thing that you needed but you never thought you would get – at least that easily. But, come on: to insinuate that the simple act of committing yourself to get something accomplished will somehow make the world work in your favor seems sort of a cheap 80′s MacGyver TV show script… And yet, in retrospective, it actually shapes itself as believable.

The motivation and results loop

A friend of mine in Transientis.com just blogged the other day about how things had started to change since the day he committed himself to starting the blog. He finally got himself to undertake some plans he had been procrastinating on for quite a while. This was all because, in his case, he could feel the cogwheels turning, and that alone gave him the necessary motivation to do things to keep them turning. I sure hope he keeps at it.

Of course, this doesn’t mean that every time you commit yourself to something it will all work just the way you planned it. Sometimes you will end up in a situation that was not exactly how you pictured it initially, and other times you’ll just face shame, defeat and several body injuries (or at least 2 out of 3).

Stability

The message is: do not ever underestimate the simple act of starting. Re-read that sentence and let it sink in, because I’m pretty sure that you might have missed something there. That’s just it: the simple act of starting.

The shocking truth is that most people are afraid of starting. People love stability: the stability of their homes, the stability of their income, the stability of knowing that Friday night is poker night with the guys, or just cuddling up in the sofa and falling asleep watching TV. People just love taking things for granted – which doesn’t mean that people love the things they take for granted.

And I’m not just talking generically about the meaning of life, I’m pointing a finger at our everyday jobs in the IT industry.

Some time ago I was working on a desktop application which had a small yet faithful user base. It was one of a kind, it did amazing things and had absolutely no substitute product.

Having no substitute product AND a small yet faithful user base can be great because it means that the developers can work closely with the users, and gather enormous and meaningful feedback to improve the product. On the other hand it also means that the users have to use it even if it required them to type text using Morse code through a serial computer port connected telegraph machine. While pedalling to keep it powered.

Luckily that was not even remotely the case and, as far as I know, no such device was ever manufactured.

Still, having a devoted user base is not always a good thing; a prolonged usage of any product will see the users become attached to the great things, and will eventually take them for granted and won’t be able to imagine their everyday work without them. They will also recognize the effort that was put into making “standard” things accomplish what they are supposed to do. They will think “This is great, this works exactly like it is supposed to” even if they’re just referring to the “Exit Application” button.

The big problem is the things that the users will just settle to live with. These are the things that the users will find weird at first, but after some days they’ll just keep on using it without quite being able to place the finger on what’s wrong. Some of them will be so in love with the whole product, that when facing these minor annoyances they’ll just say “Honey, it’s not you; it’s me.”.

The bad news is that, most of the time, the developers are not able to understand that there’s anything wrong at all – or if they do, they just face it as a minor problem. They have been so enthralled by their creation for so long that they actually learned to love it unconditionally. Luckily though, beauty is in the eye of the beholder, and useful feedback is in the frustrations of the first-time users.

The epiphany

If you never had the chance of watching users without previous experience with your product or application interact with it, I think it is time you should. There’s just an enormous amount of feedback to be taken from such experiences, but I digress – that’s another topic I want to go back to another time. Still, that was what I was doing at the time: reviewing first-user interactions, completing and prioritizing a backlog of issues related to user interaction with our product. These ranged from things that were immediate in the user tests to things that dated back to the beginning of time but had never been done.

I already had a fair share of experience with the application, so I fit perfectly in the devotee stereotype – for good and for worse. I was used to it being that way, and I liked the stability that, even though it wasn’t 100% perfect, it worked – and reliably at that. I took the functionality and the design for granted – it was there and I grew accustomed to it. The risk of changing something for worse actually frightened me, because of the whole impact it would have on everyone: I would ruin everyone’s stability. As such, I just tried to focus on doing just enough to solve – or lessen the impact – of the exact problems we had identified.

To improve this particular user interface, since there were no direct substitute products, I had to investigate a bit to see how – and if – others were tackling this same problem.

During these investigations, I stumbled upon a particular application whose main focus was a specific part of the area of our application which I was working on. My first reaction was “So this is how it should look.”. I had been the one who had lived with our application’s minor quirks, saying “No honey, that dress doesn’t make you look fat, don’t be silly.” because I had never been able to picture it in a different – slightly sexier – outfit. And at that moment I committed myself to realize this vision, to change that user interface and help our team deliver something grand. No more hit and run jobs, with the fear of compromising some other aspect of the big picture. No pressure on fixing the misbehaviours one by one. I was thinking on a grander scale now, I was going to try and change the causes, and not correct the consequences.

Of course, it would have been too self-assured of me to think “Ha, how come no one has thought of this first?”. The truth is, most likely many people thought of it first for our application – and actually tried it before – but for one reason or the other it had ended up that way because it was the way that it could be. But that wouldn’t demotivate me. I had committed myself to start. And so I did. I just prototyped the simple cosmetic change, and suddenly it did not seem like the same application – and people would stare at it at first, but when they felt it in action the couldn’t quite place why it felt different, yet strangely normal. Apparently, I had managed to change things without compromising everybody’s stability.

To cut a long story short, the limits to the greatness we could achieve were actually the DHTMLEdit’s VB6 control’s limitations: soon after I started hacking and slashing through it, and some hallway usability tests later, I realized why it had been done the way it was in the first place. Though this different approach solved a few problems, it actually introduced some unwelcome minor glitches. It was different, but I wasn’t sure that it was better overall. The stability had shaken not in a good way, the “vision” had to be re-focused.

The good thing though is that now the cogwheels are turning, the world is spinning, everything is in motion. Colleagues drop by with suggestions on how to work around the problems I face in this path. People are actually envisioning things, and are motivated by it.

Eventually we will settle for something that may not be what the initial vision was like, but hopefully it will be different from the starting point. If we can pull it off, it will be new, refreshing, and most important of all, easier to work with. And if it proves wrong, well, worst-case scenario, we always have our CVS repository to revert the changes. It is a win-win situation most of the time.

Conclusion

The points I’m trying to make are:

• You should not have to live with something that just doesn’t feel as right as it should. Don’t be afraid to question anything that’s stable, yet feels wrong. In some cases, it might not only be stabl, it might be stale.
• Starting is the single most important action to changing things. You don’t always have to know where you want to end before you start; you just have to know that you want to go somewhere else.
• Different isn’t (always) bad. And for what is worth, if the change makes you see things from a different perspective, that experience alone is worth the effort even if you end up going back to the starting point. If that’s the case, don’t beat yourself up too hard – failure only happens to those who have the will to try and do something.

Do these make sense to you?

Here you can expect to read random thoughts, insights, provocations and rants about technology, management, usability and almost any totally unrelated subject one could possibly chat around in a regular office break, from general news to the meaning of life, if deemed appropriate.

It has been quite a dillema to pick a name for the blog. The endless discussions, the web searches to strive for uniqueness, an easy URL, the despair of having a perfectly good blog name just to find out that it has already been taken by some other blog whose only signs of activity actually date back from the-days-before-the-internet… It could almost be compared to picking the name to a child of yours: a great name could open a path to fame, success and stardom, as well as a bad name could make your kid the ugly duckling in the classroom, the one who gets picked on by the others and always has to spell out the name for others to write it. Luckily, I’m not looking for fame, success and stardom – at least not here – and I had my regular share of being picked on while in prep-school, so I’m sort of confortable with it.

Sure, some might say that it is totally unrelated, but I’m sure they’re just trying to steal my thunder from this first post!

To be honest, I can’t say that “The Word Around The Office” was my first choice – I don’t even believe it was in the top 20 list – but the blog name:

a) was easy to remember,

b) was catchy,

c) was great to spread by word of mouth, and

d) was available.

Obviously these expectations were short lived because I soon realized that “wordaroundtheoffice.wordpress.com”, though highly rememberable, is not a very typing-friendly address… So it became “watoffice.wordpress.com”, at least until I figure something out.

Cheers!