At last the production of “Escape from Basecamp”, our last Teamwork promo, is out!

please watch it and leave your comments!

Don’t make me think. — Steve Krug

The most common mistake made on software products usability is to overlook the user mental model that describes the task your software is enabling. That model is a combination of real world experience, other software experience and general computer experience. User’s approach is defined by his experience and the more your application has a familiar behavior, the more will be appreciate by users. As applications are made by programmers, their interface and workflow behaviour are based on technical and incomprehensive solutions that scare and demotivate usability. We also had this kind of approach and hardly are trying to clean our minds from that attitude; at the beginning of our software product experience our aproach was driven by the standard old style software product, made by datagrid (full of data), data-forms (enormous pages full of input fields, textareas, checkboxes), reports… without any care about the user approach and application sexappeal.

One of the most useful tool to verify the usability of your application is to observe users while are using your application.

Some weeks ago we made a video test on Teamwork using usertesting.com service and the result had been impressive… really!  most of the difficulties the tester had where so obvious that we felt stupid but we never thought at them as GUI impediments. So in few days we work on each of this stupid impediments that let our application to be unusable and with little adjustments (most on feedback behaviors) we make a more comfortable Teamwork .

If you want to know more please read this article on Notes on usability, game mechanics, and Teamwork’s evolution.

So, first of all we have to reflect the User’s Mental Model to be shore that usability will not be a discriminate for users choice; the mental model your users have should infuse the design of your application’s user interface. It should inform the layout of your application’s windows, the selection and organization of icons and controls in the toolbars, the functionality of panels, etc.; try to avoid using modes that lock users into one operation and prevent them from working on anything else until that operation is completed.

In addition to seeing the results of their actions, users need immediate feedback when they operate controls and status reports during lengthy operations. Your application should respond to every user action with some visible change. Provide extensive feedback and communication at every stage so users feel that they have enough information to make the right choices.

The first porpoise of an application is, of course, to complete a task, but the importance of an application’s appearance should not be underestimated. The  appearance has a strong impact on functionality. An application that appears cluttered or illogical is hard to understand and use. “Aesthetic integrity is not a measure of how beautiful your application is. It’s a measure of how well the appearance of your application integrates with its function”.

keep the design as simple as possible, a simple design is a good design and the best tools are those that users are not even aware they are using. The more complex your application’s task, the more important it is to keep the user interface simple and focused. Your product should look pleasant on the screen, even when viewed for a long time.

Another important point is to stimulate discovery; encourage your users to discover functionality by providing cues about how to use user interface elements. If an element is clickable, for example, it must appear that way, or a user may never try clicking it.

I suggest to read carefully some interesting articles and guides about Human Interfaces:

• Notes on usability, game mechanics, and Teamwork’s evolution
• Apple Human Interface Guidelines
• Human Interface Guidelines
• Java Look and Feel Design Guidelines
• Top 10 Usability Highs…
• for fun…

How do mbComponents work in the real world applications?
Teamwork is an example… an exhaustive example!

When we decided to develop Teamwork we were not even sure which was the best development environment to adopt; we knew that the application should have been web based (it was at the beginning of 2002) and we started developing it in asp.
We had no idea what making a software product means, we had no real experience about GUI usability or how dark the web developer jungle would be (and still is) with all the differences between browser’ behaviors, CSS interpretation, different events models.
The first interface model was thought flash based (actionScript + xml) but, fortunately, we suddenly changed idea; those kinds of interfaces can work just on simple and monothematic applications!
Finally we made the best choice!! A java application based on the Hibernate framework, integrated with Lucene; it’s cross platform, cross DB, …etc.

We started using javascript but most of DOM manipulation was realized server side, on the response after a submit; just reload the page and the DOM’ll be changed! (But that was what technology offered at that time). There was skepticism on DOM manipulation, an application was thought as a form with a list, nothing more, nothing else.

Everything goes on!
Before jQuery (4 or 5 years ago) we already had components like orderable table line to set order factors, droppable portlets to customize application pages,  drop down tree menu, a tree visualizer, etc.  Almost all that we have now… but developer with great pain and what a heavy code! That was when I started hating IE and it’s bizarre, unsupportable behaviors! (But this is another story.)

All my javascript components  have been developed because of our  platform needs; at the beginning they were realized writing tons of code hacking.

Lets talk about Now!
Teamwork is a rich, full featured, complex web based software for managing projects. At a certain point we had the feeling that this complexity was damaging the usability of the application! It wasn’t just a feel… it was the truth!
For example: once installed, Teamwork 3 presents you an empty page…!!! An Empty Page!!!  It was almost impossible to start any project because you wouldn’t know how to do that (you had do give a look at ALL the video tutorials to start the complex work)! To store the first project you had to know everything about the security model in Teamwork just because nothing was preset, than you had to set an Area, than a resource… and nothing was explained directly!

Teamwork 4 …
So we start a hard work on usability.
First of all “the look&feel“:

• more affordable containers (mb)Containers
• icons that explain the functionality
  
• bigger font size and more explicit descriptions with tooltip (mb)Tooltip
• a ribbonbar that brings clearly which possible actions the users can perform  (mb)Ribbonbar soonly!
• … and so on
  

We really beleave that “more is more”,
but that is true just if this “more” is easy to get!
So we start working on accessibility.
First of all, once the user logs in for the first time in Teamwork 4, the most configurations are preset so that she can start immediately her work; she’s introduced to each application’s functionality by a clear, well explained interface with few boxes containing grouped links; it’s really easy to start!

And It’s really easy to use too!
We transformed the homepage so that the most commons actions like inserting work logs or to-dos, accessing most used information, alerts, assignments and so on are just at one click distance. Than we introduce the possibility to personalize the homepage so that everyone can view immediately what he really needs.

The feel of the user interface is now something more than just a data entry form! It’s proactive, suggesting the user what is going on and trying to keep the information in a smart way, performing a massive use of ajax to store changes, modify views, manage lists, etc. that increase dramatically performance and gives a smooth approach to usability!

It’s quite unbelievable how just working on simplifying procedures and “smartifying” responses, transform a complex framework into an easy to use, affordable tool!

We adopted jQuery as our javascript library because of its traversing DOM features, the smart syntax, its cross platform and cross browser compatibility (sort of), and its great event manipulation model and we integrated it easily with all our Java platform components giving us the opportunity to realize all the smart features you can experience using Teamwork 4.

It also increases my enthusiasm on developing useful components for experiencing the web!

go to Teamwork site: http://www.twproject.com
Try Teamwork on line: http://demo.twproject.com
view Teamwork guide: teamwork_4_guide

go to mbComponents: http://www.open-lab.com/mb.ideas/index.html