Search by author

Michael Dubakov

1 day ago

Agile Software Development Process: 90 Months of Evolution

Three years ago I wrote an article that describes the changes in our Agile software development processes from 2008 to 2012. Three more years have passed by and our processes were not set in stone. Here I want to provide you with 90 months of changes in our product development practices, company culture, structure and engineering practices. Hope you will find it interesting and learn from our mistakes.

Read the article: Agile Software Development Process: 90 Months of Evolution

Teams structure evolution

2 months ago

Minimal Action Energy Principle in User Interface Design

In physics there is an interesting fundamental principle: a system moves from one state to another using the minimal path, i.e. a path that demands the minimum energy.

Three_paths_from_A_to_B

When I read this, I immediately think about user interface design. Can we apply this principle to UI? It seems yes, since it is quite fundamental. I have never heard of attempts to use energy to evaluate efficiency of UI. This is the first try.

Let’s say, we have several interfaces that can transfer a user from state A to state B. Which one is the best? The Minimal Action Energy Principle in User Interface states:

From all available interfaces that transfer a user from state A to state B we should select the one with the minimum action energy.

So what is energy? That is a very tricky question, even in physics. But humans are more simple, so we can define all processes where we loose energy: clicking, taping, scrolling, looking/thinking, moving the mouse cursor, waiting, typing, asking for help, screaming, etc. A more complex thing is to unify these actions and have the same units for them to come up with a single energy number. After that we can compare energy of user interfaces and find the one with the minimal energy required to complete some action.

We can start with a simple model that will be good enough for the tests. We should introduce a unit to measure User Interface Action Energy. It can be yellow frogs, but let’s call it Action Units (au). All actions can be expressed via this unit:

1 click / tap = 1 au
1 scroll movement / wheel rotation = 2 au
1 second of thinking / looking = 3 au (thinking is hard)
1 second of cursor movement = 1 au
1 second of waiting = 0.5 au
1 second of typing = 2 au
1 second of asking for help = we fucked up

If I missed some interaction patterns let me know. Now we have a model to measure User Interface Action Energy. Note that energy is not equal to time. It means the user can actually spend more time with a system, but apply less energy to complete the tasks.

Let’s calculate User Interface Action Energy for a simple login action:

login_energyLooking at the form: 1
Click the email input field: 1
Recall your email: 1
Type the email: 3
Press Tab: 0.5
Recall the password: 2
Type the password: 3
Press Tab: 0.5
Realize it doesn’t highlight the login button: 6
Click the login button: 1
Wait 20 seconds to log in: 10
Total: 29 au

This decomposition makes it clear where we have energy leaks! Let’t fix it to spend less energy:

Looking at the form: 1
Click the email input field: 1 (This field should have the focus by default).
Recall your email: 1
Type the email: 3 (autocompletion can save some au)
Press Tab: 0.5
Recall the password: 2
Type the password: 3
Press Tab: 0.5
Realize it doesn’t highlight the login button: 6 (Tab navigation should work and highlight the button. Note that confusion causes a significant increase in the energy required to complete the scenario).
Push Enter to log in: 0.5
Wait 20 seconds to actually log in: 10 (Warm-up the application to reduce this time to 6 seconds that equals to 3 au)
Total: 13.5 au

This design is two times more efficient since it takes two times less energy to complete the task. Can we do even better? Yes, implement the Login scenario using the Facebook auto-fill button. This solution eliminates thinking completely.

1_login_500px_miniLooking at the form: 1
Click the Facebook button: 1
Wait: 3
Total 5 au

The absolute nirvana of UI is zero energy. You do nothing and authenticate. Is it possible? Yes, but it will compromise security. Is it possible to do that securely? For example, you navigate to an application, the device takes your picture, recognizes your live face (the photo should not work) and logs you in. You do nothing, but still wait for some seconds most likely. So total the Action Energy will be around 2 au.

Time != Energy

Usability testing is not new and clicks counting is not new. Usually we just measure the time to complete a task, observe bottlenecks and try to fix them. However, time should not be the ultimate measure of a user interface. Most likely, thinking is the most energy-heavy activity, so the best thing a designer can do is to remove thinking from the user interface as much as possible. Steve Krug was right. Some extra clicks might be OK if they reduce thinking about UI.

Moreover, a usability test doesn’t give you a breakthrough. You can find some leaks, confusions, etc., but to radically improve a solution you should think hard. When testing a basic login form you will not find a solution with the Facebook button. This solution evolves from other activities, like brainstorming, taking a shower, walking, etc.

The designer’s job is to think. The user’s job is to use the tool with ease.

Ideally, the designer should create several solutions, select the ones with a lower action energy and test them with real users to find the solution with the minimum action energy.

Automation

I think we can automate action energy measurements. Now we have quite advanced equipment to measure the eye movement, the heart rate, clicks, cursor movements, etc. In theory it is possible to create a software that will calculate User Interface Action Energy for every scenario automatically during live usability tests.

For remote usability tests where we have a limited access to a real person’s data we can measure action energy with a good approximation. Still it will be a more objective metric than just empirical observation.

TL; DR

  1. Estimate UI efficiency with User Interface Action Energy, not time or some empirical observations.
  2. Action energy includes all processes where the user looses energy like clicking, taping, scrolling, looking/thinking, moving the mouse cursor, waiting, typing, asking for help, screaming, etc.
  3. Create several solutions and test the most promising ones to calculate Action Energy. Find the solution with the minimal UIAE and it will be the most efficient one.
  4. Confusion, thinking and dead end routes are the main causes of energy leaks in UI.
3 months ago

We are going to remove Targetprocess v.2 in Jan 2016

Targetprocess logo v2-v3

Targetprocess v.2 was released in 2006. 10 years is a huge timeframe in SaaS world, so we are going to completely remove Targetprocess v.2 soon.

Most of you already work with v.3 user interface and you’ll hardly notice any difference. This post answers some questions that may trouble you. Please, don’t hesitate to ask more in comments.

Why do you want to remove v.2?

Basically, it affects our development speed. We have to run all old tests, try to not break old things and fix if they break. Less and less people use v.2, so we think we reached a safe moment to cut it completely.

There are some features I use in v.2, since there are no good replacements in v.3

We are going to match almost all features. At least it will be possible to do almost all the things in v.3 as well, like Split, Merge, etc. This is a prerequisite to remove v.2 for us. You can mention any particular case in comments and we will take it into consideration.

I love v.2 and we have On-Site installation

It means you will not be able to upgrade to newer version from Jan 2016. Most likely nothing changes for you, since we didn’t improve v.2 last two years.

I love v.2 and we have On-Demand account

In this case we will move your account to a separate server and will not upgrade this account anymore.

If you have more questions, please feel free to ask them.

4 months ago

Targetprocess 3.7.1: Better Relations and Usability

This release contains several usability and functionality improvements.

Relations as cards on a view

In previous releases it was very difficult to create Views with relations, and many times it was impossible to see all the relations at once because it’s not possible to choose cards of different types, like Features and Projects, at the same time.

Now you can use inbound or outbound relations as cards on a view. In the example below, we’ve selected Features as lanes and inbound relations for cards.  We can easily see all the inbound relations for our Features, regardless of the type of the related card:

Relations as Cards

Planned Start/End dates for Projects

Previously a Project could only have actual start and end dates, it was not possible to compare a planned start date with the real start date. We’ve unified this and now you can set the Planned Start Date and the Planned End Date for any Project.

Collections in Calculated Custom Fields

Calculated custom fields were introduced last month, but it was not possible to use collections in calculations. For example, you have a User Story with several Bugs and you want to see how much effort is required for the related Bugs. Now you can create “Total Bugs Effort” custom field for User Story and use formula:

Bugs.Sum(Effort)

Or you can calculate effort of all related entities. Let’s say, you have a feature in some project and you link other features from other projects to this feature.

InboundAssignables.Sum(Effort)

With this release all available resource collections are now supported. To learn more about collections, check the resource description.

Allow to copy text by double-clicking on description

For years you were able to edit an entity description by clicking on it. However, it complicated selecting text and copying it. So, we decided to add an Edit button. You might have to re-learn some old usage patterns, but it seems this solution is better:

Edit Description

Ability to assign Requests to a team via the POP plugin

You can now assign Requests to teams by using rule similar to:

then assign to team 1234

or

then create private request in project projectID and attach request to team teamID

Save images in WYSIWYG as Attachments

When you insert an image into the WYSIWYG editor it is now added as an attachment. This solves a security issue with static files and unifies how images are stored in Targetprocess.

Fixes

Schedule your personal demo

Our product specialists will show you the beauty
and power of Targetprocess 3 and help you to customize
it for your process and business requirements

Request

Get your free account now

Over 6000 teams
in 50+ countries start their day with us.
Welcome on board.