Task Context and the NetBeans IDE

This document is meant to gather ideas about various areas in the NetBeans IDE where a task context could be involved. Is in no way a detailed spec and is WORK IN PROGRESS.

Generally speaking there are two distinct moments when a task context will have an impact on the IDE:

  • when a task becomes activated (the user starts to work on a task) or deactivated (the user stops to work on a task) - the state of the IDE should change accordingly to the tasks context, taking in count:
    • if the task was activated for the first time and the context doesn't contain anything interesting yet,
    • if there was already some previous user activity.
    • specific user settings about what and how it has to be restored
  • while some task is active - the information about interesting context elements will also be reflected in the IDE UI

Restoring the IDE state

(or setting up the initial one).

A possible list of candidates:

Present interesting context information

  • in a dedicated context view - present the elements from a context in a organized form. Could work as a visualisation as well as a navigation and access aid for elements like files or breakpoints.
  • in result views - various features in the IDE come with result lists which might be organized accordingly to the currently activated tasks context
    • by sorting interesting elements on top
    • by highlighting interesting elements
    • by hiding not interesting elements

This might apply to e.g. textual search, find usages, find type

  • versioning - organize changed files into change-lists grouped by during what tasks they have been touched. While this might be considered a wrong working practice and be a source of user errors it still might be useful in some scenarios and a similar feature was already requested - see also issue 201514

User Experience Aspects of Task Context

Problem Statement

In any development organization, there are inevitable attempts to formalize and mature the process by which work is completed. This space is collectively known as Application Lifecycle Management (ALM). This can be comprised of many parts, such as issue and bug tracking, task management, versioning, code review and oversight, quality control and testing, build management in the like. However, at the end of the day, every aspect of ALM can be broken down into measures of work, typically called tasks or work items. A task could be a bug fix, a feature enhancement, a unit test, even something esoteric or early like functional diagramming. In each of these instances, it is important that the development team resource be given efficient access to the tools, artifacts, and data pertinent to that task. In large development organizations, as well as work on large-scale development projects, it is often the case that developers "can't see the forest for the trees", that is, there are so many tools, too many artifacts, and way too much data, such that they cannot ascertain what is pertinent and what isn't. This leads to developers spending more time doing forensics than actual work. It can also lead to more catastrophic situations like versioning conflicts, duplication of effort, or even lost code or data.

Task Context, Defined

A task context is, simply put, all of the items a developer (or other team resource) might need in order to go about completion of a task:

  • Instructions
    • Description of task
    • Inputs to the task
      • Existing Code
      • Documentation
      • Test Results
      • Bug Reports
      • Requirements/Enhancement Request
  • Pertinent Code Artifacts
    • Common Interfaces, Classes, Frameworks
    • Prototypes and Pseudo-code
    • Code to be manipulated or augmented
  • Environmental Variables
    • Codebase to work from
    • Build, Compile, and Project Management parameters
    • JDK version
  • Metadata
    • Notes
    • Subtasks, steps
    • Priorities and Deadlines
    • Related tasks, other resources working on related areas

In general, though, the items that feed a task context are specific to the type of task.

Task Context, by Task Type

It is important to note that depending on what the task is, the items required for a task context would change. Some example:

Feature or Enhancement

When a developer is tasked with implementing a new feature, there will very likely be few pre-existing code artifacts that pertain to the task, at least at the outset. The expectation is rather that these artifacts will be the work product of the task. Instead, inputs to the process are likely the enhancement request itself, perhaps requirements or functional specifications, and in some organizations, prescribed implementation steps such as common frameworks or classes to use or extend. In iteration on the new feature, items like UI mockups, wikis, and various file versions might also get added to the mix.

Bug Fix

In the case of a bug fix, developers will most likely be working from a set of existing code. They might also need access to unit and QA testing results, but more importantly, they need to be able to accurately recreate the testing environment so that they can debug, replicate, and eventually fix. Things like environmental and input variables become important in the context of this type of task. Trace and diagnostic logs might be shared with the developer. The output or work product of this task type is likely a transaction upon the version control system, which should of course be associated back to the task and its context, for traceability.

QA and Testing

For members of the development organization that focus on QA, the inputs to the task will likely be the code being tested, the test plan, the input and environmental variables, and the requisite set of tools for running the test. If this is an iterative process, the QA resource might also need access to previous tests run in this or related areas of the code. The output will be build logs, test results, and updates to bug reports or issue tracking systems.


For PMs, development leads, and others who are involved in prototyping early on in the development lifecycle, the task context is comprised of artifacts like requirements, functional diagrams, mockups and wireframes, and the tools within the IDE available for prototyping. The output, in most cases, would actually be the tasks assigned to development to actually implement the capabilities proposed by the prototype.

Possible Approaches to Establishing Context in the IDE

In investigations of Task Context in other IDEs, as well as other work and team management systems, there seems to be a few approaches. We will call these "light", "medium", and "heavy", alluding to the level to which the features proposed affect the base look-and-feel and functionality of the IDE.

"Light" Task Context Interventions

The following features do not constrain or morph the IDE in a manner which would jar or confuse the developer:

  • Providing or opening a set of files associated with the task context (but without replacing or filtering the IDE's base file/application navigation UI)
  • Opening a dedicated Task Management area as a panel within the IDE
  • Highlighting areas of code that are known to be associated with the task
  • Suggesting potential artifacts of interest, related tasks, developers working on related areas of code

"Medium" Task Context Interventions

  • Restoring the panels in the IDE to the way they looked the last time the task was "activated": size, position, dock state, visibility.
  • Adding or promoting menus or toolbars that expose toolspertinent to the task at hand
  • Closing files that are known not to be pertinent to the task at hand.
  • Re-organizing the IDE's base file/application navigation UI to promote artifacts pertinent to the task (but not removing/filtering any of the items shown)
  • Providing a "perspective-shift" similar to how things are done in the Eclipse IDE, based on the type of task that was activated

"Heavy" Task Context Interventions

  • Filtering the IDE's base file/application navigation UI to only show files known to be pertinent to the task
  • Only showing menus and toolbars known to be related to the task.
  • Changing project properties, build or environment variables, and the like to customize the IDE's behavior to the task.
  • Prioritizing or ordering task context artifacts based on some automated interpretation of their "degree of interest"
  • Setting code artifacts to specific versions/labels/transactions from version control

"Right-Sizing" Task Contexts

In light of the discussion above, it is key that we ensure that the interventions and augmentations that our Task Context feature makes upon the IDE hit the sweet spot where it helps developers be more efficient, but isn't so heavy-handed that their entire world changes and they don't feel like they know how to interact with the IDE they've grown to know. It's important to note that the majority of developers are VERY particular about how their environments are set up. Moreover, most developers have ALM tools forced upon them by management, because they allow development leadership to track progress, to have purview and traceability, and to effectively manage development projects and balance resources. Therefore, we have to create a scenario where we have enough of an intervention to have an impact, but not to the point where we irritate or alienate the end users.

A Proposal

Here is a modest proposal, as a first cut, for how to go about establishing Task Contexts in such a way as to accomplish the goals above:

  • Implement all of the "light" interventions as a matter of course
  • Take a good look at the "medium" interventions and implement them based on task type. If you look at, for example, manipulating menus and toolbars, or "perspective-shift", this might be more palatable in the context of, say, QA or prototyping than it would be for feature request implementation or bug fixing.
  • Identify which of the "heavy" interventions are technically possible, and make them optional based on user preference, but turned off by default. (or very easy to turn off without hunting through a lot of menus)

Updated Proposal: 02/19/2012

The NetBeans Task-Focused team met to discuss the possibilities surrounding customizing the IDE for Task Contexts, and made the following decisions:

  • Task Contexts should be shown in a new window that, by default, is docked in the same location as NetBeans' current Navigator window.
  • The currently Active Task should persist in the Navigator window, not the task selected in the Task Dashboard.
  • The information shown in the Task Context window should consist of a combination of the following:
    • Associated Files: A combination of files that are automatically populated by using MyLyn's automation around "degree of interest" along with files that have been manually added by the user. This is intended to be a scaled down version of the Files/Projects views, specific to the Active Task.
    • IDE State: This is an area where the user can select to Save or Restore aspects of Netbean's look and feel. The user should be able to configure preferences that specify the degree to which they want the IDE customized based on a Task. These preferences are:
      • What files to open
      • What windows/dockables to open, as well as size, position, and dock state
      • Versioning preferences
      • Breakpoints
      • Bookmarks
      • Profiles state and settings
      • TBD: Level of state save/restore for individual windows. For example: in a file editor, should we save and restore whether or not the user was on Source, Design, or History? What about the toggle state of category nodes in the Property Inspector?
      • TBD: Custom task context "profiles" for different types of tasks. Should we allow users to save different preferences for different tasks, so that in some cases, task contexts only tweak the IDE minimally, but for others, there is a lot more intervention?

Update: 04/02/2012

There are two attachments that we've generated to exemplify the direction we're taking for Task Contexts:

Next Steps

In order to firm up this proposal, two UX activities are recommended:

  • review task contexts in existing IDEs.
  • talk to process experts about the general concept of Task Contexts, outside of any specific IDE. Make sure to get equal representation from both Oracle internals like the Development Process Champions group, as well as external NetBeans community developers and contributors.


For questions and concerns, contact Rich Gunther at rich.gunther@oracle.com, NetBeans.org username: RichGunther

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo