Plunet 6.2 to 6.3 to 7.0

Plunet was one of the first companies to create standalone translation business management software. In fact, it could be said that they single-handedly developed the market since their introduction of the first Plunet software version in 2003. This genre of product transcends project workflow to include customer relationship management functionality, marketing support, financial management and reporting. Yet Plunet has never been positioned to be all things to all users. For example, Plunet doesn’t include translation memory functionality, nor does it pretend to be a fully-featured accounting package.

These speciality functions are left to speciality products. Instead, Plunet takes the role of maître d’, guiding users to a smörgåsbord of options and overseeing delivery by individual contributors. Plunet has focused on connectivity to specialized products so that customers are at liberty to choose the technology mix that best suits their needs.

Plunet’s long history in standalone translation business management software is an advantage and a disadvantage. The product has reached a state of robustness and maturity that is unrivaled within the segment, and the company has benefited from customer input extending over years. On the other hand, aspects of Plunet’s user interface (UI) have been a source of criticism even among long-time proponents of the software. Newer entrants to the market have had the advantage of learning from Plunet’s design. This has allowed them to create intuitively compelling user interfaces. But, let’s not fall into the trap of judging a book only by its cover.

As Plunet has matured, the architects have chosen to take an evolutionary approach to rectifying perceived deficiencies. Plunet’s evolution reflects a mix of architectural vision and incorporation of user feedback. The 6.2 version, for example, replaced the middle row of three horizontal rows of menu choices with drop-down menus. Many users might have deemed this structure as being more intuitive because it was more in line with “classical” menu design. Such intuitiveness might be a by-product of users’ familiarity with long-standing generic software designs, but many users surely found themselves closer to their comfort zone. That said, the company isn’t without a certain Teutonic stubbornness about certain core design issues.

There comes a time in the life cycle of every software product when the designers have to go back to the drawing board to take a good hard look at what they have created. First-mover products that boldly create application categories are no exception. Early architectural decisions become dated as market categories mature. Competitive products appear, leveraging the pioneered concepts on top of newer technological bases. Sometimes originally hot technological substructures themselves become obsolete through acquisition by competitors and subsequent sunsetting by the acquiring company. Thus, assumptions about technological longevity can turn out to be wrong or, in some cases, even impose severe limitations on a product’s ongoing viability. Consumer tastes are subject to change and operating environments evolve. Anyone reading this magazine has certainly witnessed the increased availability of high-speed internet. Increased expectations in application performance speed and reaction time have been a natural corollary.

Companies such as Plunet have to navigate carefully to survive and thrive. And they have to be willing to look inward when necessary. Not all of the aforementioned changes have directly impacted Plunet, but some of them have. Some of them have affected competitive products in the translation workflow space. Not every competitor has survived. Plunet has. And it has thrived and grown.

The Plunet 7.0 release represents the fruits of an introspective period in which the product designers looked primarily at how they could make the product more robust and responsive. Such changes are good news for Plunet users. They also create challenges for me as the reviewer. For example, increase in speed is both subjective to the user and a function of exogenous variables such as overall internet traffic. In absence of a capability for more scientific measurement, I am relying largely on anecdotal evidence and some theoretical projection of what ought to be perceived performance improvement, given certain circumstances.

With those caveats behind us, let’s begin with one important and visible feature that was implemented in the 6.3 version and remains in 7.0. This feature may be old news, but it hasn’t been covered in a review. The feature is important because it is very different than in predecessor Plunet versions. Furthermore, it’s central to project managers’ interaction with Plunet. The feature is the Job page.

To understand the significance of the change, you need to look at previous versions of the software. One long-standing criticism of Plunet’s interface paradigm has been the necessity to scroll vertically through tall pages to reach individual sections where user input is performed. Many versions ago, these sections would dynamically jump to the top of the page when a link in the third menu row was clicked. This caused user confusion. At some point, Plunet changed these links to quick-scroll vertically to the relevant section, which was a real improvement. Nevertheless, users — especially new users — would get lost on the page and lose context. Users would have to scroll back up to see where they were, then scroll back down to where they wanted to be.  All this scrolling costs time and brainpower that would be better devoted to other action items. Nowhere in the Plunet UI was this scrolling more problematic and critical than in the Job pages.

Plunet must be lauded for listening to users and taking corrective action. The Job page display has been entirely reworked. The reworked page was one of the most compelling reasons for existing users to migrate to the 6.3 version from 6.2 or earlier when it became available early in 2016.

The Job page now consists of a header section that remains constant to provide ongoing contextual information. The page also contains four subsection panels that can be swapped out with one mouse click. The panels are used to display detailed information and for user input. A smaller rectangular icon at the top right corner of the page provides quick toggling between the Job pages, the Order Details page, and the Resource Search page for any given order.

Let’s clarify some Plunet terminology. An Order consists of all deliverables, including source files and their translated counterparts, as well as supplemental material, such as reference files and relevant metadata. Within an order, there are Items. In most cases, an Item is a language pair, and each language pair may have multiple files associated with it. Items are broken down into Jobs. A Job is a single activity, essentially what North Americans more readily think of as a task. Typical Jobs are translation, editing and proofreading (TEP). Thus, the standard TEP workflow comprises three Jobs for each language pair that is designated as an Item. In Plunet versions through 6.3, a grouping of sequential, related jobs was called a Job Chain. Plunet has now adopted the more generally understood term Workflow to express this concept. Accordingly, Workflows are now defined in Workflow Templates. This terminology also frees Plunet from the linearity implied by a chain of jobs. The workflow naming convention is more evocative of real-world translation processes that frequently aren’t linear in nature.

The newly designed Job page is loaded as an overlay in front of the Summary view of all jobs belonging to an Item (Figure 1). Although the Summary view is grayed out in the background, it remains sufficiently visible to provide some context. This added context, combined with the new ease in toggling between job information panels, provides significant visual improvement. Despite being pleased with this new functionality, some users may still feel somewhat limited that the Job page can’t be moved aside to view more of the Summary page. This immovability could be a technical limitation imposed by the fact that the Job page is modal. But it can be irritating if you want to take a quick peek at more of the Summary view before continuing to work on the page. Nevertheless, the new layout is a great improvement over previous Plunet versions.

There’s a somewhat ironic twist to Plunet’s change of dialog paradigm that became evident during a side-by-side demo of Plunet and XTRF at memoQfest last May. Plunet’s users have provided feedback asking for a more tabbed dialog paradigm, as is now evident in the Jobs page. XTRF’s users complained that their tabbed dialogs were confusing, and so XTRF’s new “Smart Projects” job assignment interaction is much more vertically oriented. Perhaps this contrasting feedback is an indicator that the ideal UI design meets somewhere in the middle. Or, perhaps, it just indicates that whatever you do, you can never please everyone!

One of the reasons for Plunet’s success has been its agnostic view of companion translation memory technologies. Listing the entire range of supported translation management (TM) systems would exceed the scope of this review. But it’s important to note that, already in 6.3, extensive GroupShare support was added to the palette of choices. Plunet 7.0 features substantial enhancements to the Across crossGrid, including seamless exchange of projects between the two applications. Other supported TM solutions include SDL Trados Studio, memoQ, Memsource, and XTM. Furthermore, among other companion technology enhancements, Plunet 6.3 extended its support for memoQ in several important workflow areas.

One touted area of the 6.3 version’s memoQ support was complete and automatic round-trip file transfer from Plunet to the memoQ server and on to the translation resources. The promise of fully automated file transfer set a high expectation for efficiency gains but, unfortunately, those hopes were initially dashed. With Plunet 7.0 and memoQ, the expectation can now be fully met. So there’s a happy end to the story, although the early stages were not so pretty.

In early releases of Plunet 6.3, the round-trip cycle was incomplete. Files were transferred from Plunet to the project on the memoQ server, and then on from there to the translation personnel. These resources then worked on the files and delivered them back to the memoQ server. But that is where the automated transfer stopped. Despite being designated as “delivered” in memoQ, files didn’t get returned from memoQ to Plunet for further workflow steps. This break in the file flow meant that either the remote resource had to upload project files to Plunet as a separate, additional task, or a project manager had to move them from their storage location in the memoQ environment back to Plunet.

This nonautomated file handling requirement might seem like a low-impact item but, in the real world, getting translation resources to remember to update the status of delivered files to “delivered” in memoQ is problematic enough. Trying to convince them to consistently deliver files to two different applications is next to impossible. Time-strapped project managers get very annoyed at having to shuffle files around on behalf of other people. This extra load was a real time-robber when it had to be done multiple times each day, not to mention being a source of human error. Project managers at one of my clients used this as an excuse to resist adoption of Plunet.

The jump from 6.3 to 7.0 wasn’t a quantum leap with tons of whiz-bang, paradigm-shifting new features. But a lot of thought and care about users went into the 7.0 release. The newly redesigned online help is one of the most visible improvements. Plunet’s previous help system wasn’t really all that helpful. Finding information was difficult. When information was found, it would tell the user what onscreen elements were, where they were located, but not how to use them.

The new online help includes a “How to” FAQ section that describes many common tasks. This addition is really important. Although Plunet provides training for new deployments, project managers, who are generally an overloaded cohort, typically don’t practice what they have learned in the sessions. The moment a training session is complete, they go back to their regular duties. That is, if they haven’t been double-tasking throughout the training session. After the training series is finished, few resources remember how to accomplish even the simplest tasks. This forgetfulness isn’t Plunet’s fault, but it’s a recurring, real-world issue. Smart companies appoint a product champion who is tasked with learning and retaining the knowledge gleaned during the training sessions and, most importantly, given the time to do so. In my experience, not that many companies are smart enough to take such a proactive approach. The new online help won’t completely eradicate this problem, but it will certainly mitigate it. Kudos to Plunet for their work on behalf of their end users.

Another behavioral change in Plunet 7.0 may seem simple to some users but important to others. In prior versions, individual users could choose whether the details pane for contacts would be open or closed when a customer or resource page was loaded. Some Plunet deployments contain customers with hundreds of contacts. Loading the customer page with the details panes open for every contact resulted in extremely long load times. Plunet’s having to render each individual pane from the database caused the delay, sometimes exacerbated by heavy network traffic. This behavior frustrated users.

As of Plunet 7.0, the Customer page opens with the individual details panes closed by default. On Order pages, Items also now loaded first in read-only mode. Loading pages with subsections closed or set to read-only reduces page loading times, especially when customer contact lists are very long, or when Orders consist of many Items. Individual items can be opened quickly for editing by clicking directly within them or on the Edit icon.

There are many other little changes sprinkled throughout the UI that make navigation quicker and more intuitive. One example is the new navigation for result lists that consist of multiple pages. There’s a new page navigation area that allows you to jump directly from the first to the last page, or any page in between. The area also contains a dropdown where you can set the number of results per page. For some customers, these speed improvements alone could be a reason to upgrade.

Vendor company managers will be pleased with several new reporting capabilities. Plunet 7.0 includes a really important key performance indicator, namely Processing Time for Requests. Any vendor with the capability and the work ethic to respond to requests quickly has a definite competitive advantage. An increase in response time is a clear indicator of several potential problems. For starters, long processing time could result in lost business. It also could signal a shortage in staffing, or that a rebalancing of responsibilities is needed. Management needs to monitor response times to ensure that their resources are performing well in this area.

Company management will also be pleased to discover that additional flexibility in filtering of queries has been added in 7.0. This flexibility improves granularity in the extraction of information from the Plunet databases.

Project managers can now assign multiple jobs to one service provider in a single step. Previously, jobs had to be assigned individually, even if they were going to the same provider, and an email for each assignment was sent. Now, one email can be sent that includes all jobs assigned to the provider. Multiple assignment is especially relevant when the assignee is a subvendor that provides multiple services. An example is a single-language vendor that provides translation, editing and proofing tasks for the assigned language.

There’s an industry trend to allow customers more access into the translation process, particularly in the area of review. Customers of language service providers (LSPs) that upgraded to version 6.3 were surely happy to discover that they could be incorporated into projects as external resources. Previously, it was possible, but not elegant, to give customers access to projects because they could then see data that most vendors prefer to keep confidential.

Since Plunet’s early versions, subsuppliers such as freelancers could use their portal access to create their invoices directly using project data. From the perspective of project data consistency, this practice is useful. But it rests on an assumption that isn’t necessarily real-world, which is that the external providers work exclusively for one company. Many, if not most, such providers have multiple customers. Therefore, they can’t conveniently use Plunet as their central invoicing system, especially in taxation environments that strictly enforce numerical consistency for invoices. The 7.0 release gives suppliers freedom to use Plunet to upload invoices generated by other applications (Figure 2). This freedom keeps invoicing information, even from an external application, together with the underlying project data, so it’s easier all around for resources in the payment chain. The new right also allows providers to delete invoices that they have created. Previously, if an invoice was created by a provider within Plunet, they had no ability to delete it, for example, if they made a mistake. A project manager had to do so.

The 7.0 release includes a new template that simplifies cumulative invoices. This functionality is helpful to LSPs that invoice once per month for multiple orders. It’s accomplished by new flags that enable invoicing templates to accumulate order totals onto a single invoice without the corresponding line item detail. Previously, only experienced template builders could create this functionality, and it was quite kludgy, to say the least. The new, consolidated invoicing format greatly reduces invoice page counts. The old format remains available if more detailed invoices are required.

Enhanced support for cost center delineation is loosely associated with this use case. One of my clients consistently receives upward of 500 orders per month from one customer with two cost centers and over 100 requesters. Previously, creating cumulative invoices for each cost center meant using custom text block filtering. Cost centers can now be associated with a customer contact profile, their address, or both. When the contact creates a request, the cost center is automatically added to the request in an editable field, and propagated throughout the remainder of the order documentation. Because the field is editable, the contact is free to overwrite the cost center presented by default when creating the request. Automatic assignment of cost centers by requester will reduce the potential for human error and accelerate the invoicing process. My client is going to love this feature!

The Plunet 7.0 release quietly layers numerous little usability improvements on top of the 6.3 release. There are few highly visible, sweeping changes, but a plethora of “little somethings” for everyone. It appears to be a very solid release, one to which Plunet customers are advised to update.