product development Blog

3 days ago

Service Desk: localization and other improvements

Hi all!

It's been a while since we posted something new about Service Desk, and I am happy to share the latest changes with you.

Localization

Service Desk is now fully translated to 10 languages, all thanks to a number of awesome people who volunteered to contribute to the translation process. This is really impressive, as we did not have the chance to hire translation agencies for this feature. Such support from the community is really appreciated and makes us feel that maybe we did one or two things right.

service_desk_localized_de

The following languages are now available:

  • Dutch
  • French
  • German
  • Hungarian
  • Italian
  • Norwegian
  • Polish
  • Portuguese (Brazil)
  • Russian
  • Spanish

There is a global, default language which be set at Service Desk options by an admin, but users can select the one they individually prefer in their personal settings. This will be useful if you have people working in different locations.

New Search

It's no secret that search functionality was rather... limited in Service Desk. Basically, it searched for the exact phrase you typed, and it was rather slow. We did this on purpose back then, since we planned on reusing the awesome new search engine being developed for Targetprocess. This engine is now available in Targetprocess, and you can already find it at our own instance of Service Desk. It will be available for all Service Desk users with our next release (v.3.12.3).

Widget Builder

As you may know, you can embed a simple Widget into any page or application so that users can submit requests right from there, without using the full version of Service Desk. This is not something really new — it was already available in previous versions. However, it was not very convenient to configure it, as you would almost certainly need to consult our guide and form your Widget link by adding parameters manually. We simplified the process by allowing you to configure your Widget at Service Desk Settings:

widget_builder

Improvements in permissions

  • Targetprocess administrators will now see private requests in Service Desk, as they would in Targetprocess.
  • Request owners can see their own private requests even if they are not among requesters anymore.
  • If you are a requester or the owner of a request, you can now see the request in the My Requests list, even if the project is not available in Service Desk. This will help companies who have one project for incoming support tickets, and then distribute requests to the appropriate project by Support Team. In fact, this was the only thing preventing us from deprecating the old Help Desk portal where such a scenario was both supported and critical for some customers.

Usability improvements

  • It is now much easier to find the My Requests list, which was previously hidden under the cogwheel icon.
    my-requests
  • Targetprocess users will now see internal links to Targetprocess for requests and related items.
    links-to-tp
  • We are no longer displaying states in groups (like Open, In Progress, Done) if the projects use only one process. In this case, you will now see your actual states.
  • It is now more clear which request type is currently selected.

There were some other minor bug fixes and smaller improvements as well, such as the addition of my personal favorite black color theme.

We hope you like our Service Desk, and we'd really love to hear your thoughts and feedback.

Have a great weekend everyone!

 

2 months ago

Visual Reports Editor: Beta of cumulative, burn up & down reports

We are happy to announce the beta release of historical reports for all On-Demand accounts (with the exception of private clouds, for now).

You can see the basics of how to start using it in the image below.

howto

A full explanation on how to use historical reports can be found in our guide article: How to create a historical report

We will really appreciate your feedback on this beta release of historical reports. What do you like about it? What could be improved? Let us know what you think at ux@targetprocess.com

4 months ago

Capacity Calculation

Capacity calculation: highly anticipated and finally here! From now on, you can calculate the capacity of each user while planning Releases, Iterations, and Team Iterations. Finally, you will be able to see if a user is overloaded with tasks, or if they can take on more work in this particular iteration.

This will make it so much easier to plan your resources across one or many projects. We didn't forget those who work part-time, or those who are allocated by n% of their time for a particular project and period of time.

Available capacity will be summarized across one or many projects based on:

  • Work days in a “work container” (Release/Iterations/Team Iteration)
  • Weekly available hours by user
  • User allocations, if there are any

Capacity can be calculated for User Stories, Bugs, Tasks and Test Plan Runs. It also works for Initial Estimates for Features and Epics if there are no child entities. In other cases, they will be estimated by the sum of child entities’ effort.

Please keep in mind that effort from Tasks is not included in User Story effort for capacity calculations.

Let’s dig into a few cases and see what it looks like.

Case 1: One Project, no Allocations

This is the easiest way to plan resources if you have one project and don't use allocations.

On Boards where you see cards grouped by users and Releases/Iterations/Team Iterations, you will notice a small box in the right corner of a cell. It shows the assigned effort and capacity of a person:

screen-shot-2017-06-20-at-4-56-24-pm

When you move cards from the Backlog to a Release, the values for assigned effort and capacity are updated:

screencast-2017-07-28-18-00-25

Based on weekly available hours, we know that John works full-time, 8 hours each day. In August, we have 23 work days, so John’s capacity for July’s Release is 23*8, which equals 184 hours. When we assign a card to John, the system calculates assigned effort and compares it with available capacity.

On the next screen, you can see that John is overloaded for August's Release by 4 hours. It’s already easy to notice whether there is some spare capacity or an overhead. Cells with spare capacity are highlighted green, and cells with overhead are highlighted red.

To check the details of assigned effort and capacity, just hover your mouse over the tooltip in the right corner of a cell:

screen-shot-2017-07-31-at-11-18-53-am-2

If some supported cards are not being displayed on a board (perhaps there are some filters applied), and there is some hidden work assigned to you, the cell will show the aggregate sum of all assigned effort, including hidden cards.

screen-shot-2017-07-31-at-11-27-04-am-2

If you use points for estimation, you will be able to see the sum of assigned effort for a user in a particular Release/Iteration/Team Iteration, but not the capacity

Case 2: One Project + Allocations

Let’s dig into a case with more than one Project and user Allocations.

John will be allocated to Project Irol System for 40% of his hours, and to Mobile Platforms for 60%.

screen-shot-2017-07-31-at-11-35-56-am

The John’s capacity for July for Irol System Project was immediately updated, 40% from 184 hours equals 73.6 h

screen-shot-2017-07-31-at-11-37-08-am

 

If at least one of the users is allocated to a Project you should allocate others as well. Otherwise their capacity will be calculated on assumption that their allocation is 0%

Case 3: More than one Project + Allocations

Let’s now plan a Cross-Project Release (the scope can include work from one or more projects).

John’s allocations mean that he can dedicate 73.6 hours to Irol System and 110.4 hours to Mobile Platforms (40% and 60% accordingly):

screen-shot-2017-07-31-at-11-42-20-am-2

You can click on a few cards and see the sum of their effort. This is especially convenient when moving a few stories from the backlog!

screencast-2017-06-21-15-11-36

If you have more than 500 cards in one cell, Effort will be calculated by the first 500.

If you estimate work entities in points, capacity will not be updated. Capacity is calculated in hours only.

Case 4: Team Iterations

As you know, Teams and Team Iterations can be assigned to multiple Projects. Just keep in mind that Capacity and Assigned effort will be calculated based on work that is included in a particular Team Iteration, not based on all Projects to which a Team is assigned.

screen-shot-2017-06-21-at-3-31-23-pm-2

When Releases/Iterations/Team Iterations begin, their capacity value will be regularly updated based on the remaining amount of work days

 

4 months ago

Global search rework

As many of you know, searching for data in Targetprocess can sometimes be more time consuming than expected. Since we would all like to save some time (and search more effectively), we have reworked our global search to make it faster and more reliable.

We plan to start rolling out this new search for customers in the near future. It will be enabled gradually, because it will take some time to re-index all the data. In this regard, the new search will not be immediately available for everyone. Stay tuned. After passing all the checks, we will turn it on for every account.

Search engine replacement

Let me unveil the main change we've made to search. We deprecated our old search engine and built a new one from scratch using Elasticsearch. We chose Elasticsearch because they are a leader in the search engine market. Their engine allows us to improve results for common search tasks, such as relevant search, filtering, aggregation, etc. Replacing the old engine with a mature one simplifies any development related to search, allowing us to move faster. It will now be much easier to implement new features, such as searching by attachments, advanced filtering, and custom orderings.

Relevance of search results

As with many full text search engines, results in Elasticsearch are ordered by relevance by default. We followed the same direction, so search results in Targetprocess will now be ordered by relevance. But, as usual, the devil is in the details.

Relevance algorithm (for those who are hungry for details)

Elasticsearch uses the Term Frequency/Inverse Document Frequency (TF/IDF) algorithm for scoring document relevance.

Once we have a subset of matching documents (entities in our case), they need to be sorted by relevance. Some documents contain all the terms, while others don't. It's important to note that some terms are more important than others. The relevance score of the whole entity depends on the weight of each query term that appears in that document.

So, relevance score is determined by three factors:

1. Term frequency. How often does the term appear in this document? The more often, the higher the weight.

2. Inverse document frequency. How often does the term appear in all documents in the collection? The more often, the lower the weight.

3. Field-length norm. How long is the field? The shorter the field, the higher the weight.

Results view redesign

First, you will notice the redesigned search results view. We tried to make it more visual. Comments now are shown in search results (if you search for keywords found inside them) in a tree-style manner. This makes the search results view more consistent with our entity details view, and makes it easier to quickly scan through results. Any keywords found are highlighted, both in comments and entity fields.

Moreover, if the searched keywords are found in Custom Fields (which are all searchable now), they are also highlighted on the results view.

We've also taken some steps to improve the user experience of anyone who uses the QA area in Targetprocess. From now on, when searched keywords are mentioned in test steps, they will appear in the test case result view in a tree-style manner, similar to comments.

search-test-steps

Thanks to the changes mentioned, the results view has become more informative and allows you to easily recognize the entity you wanted to find. If the displayed meta data isn't enough, you can open the entity details view by clicking on either the 'Name' or '#ID' of the entity. Due to the fact that we improved navigation back to the search results (they are actually cached), it's now extremely fast and should save a bit of time.

Search by itself just got better. But what if your searched keywords yield too many results, and you cannot find what you're looking for? Sure, you can go through all the pages and eventually discover what you wanted to find, but there should be a better way. For this, you can use filters.

Filters area

Filters allow you to narrow your search results. You can find the filters area to the left of the result list on the search view.

In many cases you are interested in only one or several types of entity. For this, you can just use the 'ENTITY TYPE' filter and only desired type of entities will be searched among. The filter allows you to select one, several and all types and even have it's own search for faster navigation to the target type.

filter-entity-type

If you know which states your target entity could be in, use the 'ENTITY STATE' filter, which is identical to the type filter functionality.

filter-entity-state

It's worth mentioning that type and state filters are dependent on each other. Once you select some types, you can only choose states that are relevant for the for the selected types, and vice versa.

In some other real situation, you may want to find entities that are either hot (were created during the past month) or completely archaic. Just use the brand new 'CREATE DATE' filter. It signals search to take into account only entities that were created during the selected period.

As it was before, the 'All Projects and Teams' checkbox is still present in the filters area and available for usage. It is now enabled by default. Uncheck it to search through currently selected Projects and Teams. Otherwise entities from all Projects and Teams available for you will be considered. We assume that global search should behave globally by default, while narrowing should be an option, not a preset setting.

filter-all-projects-and-team

Advanced syntax

We did our best to make search relevant and useful right out of the box. In most cases, you won't need to take any steps beyond writing several keywords in the search input. If needed, search can be fine-tuned to solve the most exacting cases.  These are cases where the advanced grammar of search can help you get things done. The following table describes a bunch of special characters which can be used in the search input:

CharacterExampleMeaning
+big + elephant

"big elephant" + "small giraffe"

Signifies AND operation. Searches for entities with both words included (or for phrases, if enclosed in quotes).
|elephant | giraffeSignifies OR operation. Searches for entities with at least one of these words included.
"""Exact phrase"Exact match. Finds all entities which contain the exact phrase from the search query.
*eleph*Search by prefix. Finds all words starting with 'eleph' (slows down searching significantly!).
~Nelefant~2

"big elefant"~2

After a word, this signifies edit distance (fuzziness). Suppresses emphasizing of mistakes on the search string (slows down searching significantly!).

After a phrase, this signifies slop amount. Allows other words to appear between words in the phrase (slows down searching significantly!).

Search sources

Global Search scans the following fields of Targetprocess entities: 'Name', 'Description', and text from all 'Custom Fields'. Searching by TagsTime Descriptions, and Attachments is not yet supported yet, nor is searching through entities in inactive Projects.
Compared to the old search, we have added a couple of new search sources. So, it's now possible to search among Projects and Teams.

2017-07-28_1728