TaskContextUseCases

Contents

Task Context Use Cases

This document describes the basic use cases when working with tasks and their IDE relevant context.

Introduction

The following top level use cases are meant to describe in a general way the behaviour of context aware areas in the IDE. For the purpose of this document we will understand a task context as all information given by the IDE which is potentially related and relevant to a specific task. One context is always associated with one task. A context consists of context elements which might be either user objects (software artefacts/resources like e.g. files or projects) or settings (e.g. breakpoints, the visibility state or scope of a specific view, etc.). Based on user activity in the IDE, task relevant information will be gathered into a context and later used to restore the state of the IDE when the user switches between tasks.

For a discussion regarding context elements see here

For specifics about the particular context aware areas included into a task context see the context design specification

For more information see also the context discussion.

Setup

The user wants to fine tune how, when and from what parts of the IDE is the task context information gathered and in what way it effects the further behaviour of IDE. For this purpose he opens the tasks contexts preference page in the IDEs preferences/options UI. Each context aware area comes with a set of specific settings.

Example: The user can setup that all touched and currently opened files are supposed to be added to the context, but that only the currently opened files should be opened the next time a context is activated.

Activating/Deactivating

Activating a context

The user decides he has to work on a task and explicitly activates it. Activating a task also automatically activates its context. There is always only one active task/context at a time. In case there is currently some another task/context active, then it also will be automatically deactivated.

By default the IDE restores its state on context activation accordingly to the state when the context was previously deactivated.

Example: After activating a task the list of opened projects and files changes to the state as it was at the moment when the context was the last time deactivated, debugger breakpoints and watches which aren't associated with the task disappear, the scope of the versioning status view is changed as well.

TODO is there any reason to expect that after activating a context something else should happen than the described default - e.g. that all context files should be opened instead of the files which are currently open?

Initially activate a context

The user activates a task/context for the first time. No matter if a task is or isn't active, given by user preferences the IDE either stays as it is or falls back on an "empty" initial state.

Example 1: There is an active task in the IDE. Some projects and files are open, some breakpoints are set. After activating a new task all opened files are closed, the list of projects remains as it is, all breakpoints are removed.

Example 2: There is no active task in the IDE. Some projects and files are open, some breakpoints are set. After activating a new task the IDE stays as it is, the opened files and projects become part of the context.

Deactivating a context

A task is currently active. The user decides he wants to stop working on it.

  • he either explicitly deactivates the active task
  • or activates another one. As there can be only one active task at a time, activating a task automatically deactivates the other one.

Deactivating a task also automatically deactivates its context.

Example: There is an active task in the IDE. Some projects and files are open, some breakpoints are set. After activating a new task all opened files are closed, the list of projects remains as it is, all breakpoints are removed.

TODO task-/contextless state - do we have to worry about it?

Accessing, adding and removing context elements

Viewing Context elements

There is an active task in the IDE. The user wants to access, inspect or manipulate some elements from its contexts. He opens the Context View UI which is providing an overview of the particular context elements. A context element might or might not be listed in the view depending on:

  • how easily it is accessible in its "native" views
  • if it is necessary to provide the possibility to add/remove elements of a given type to/from a context

Note: In general it is to be expected that there is no justification for non resource related context elements (settings like e.g. breakpoints, watches or VCS view scope) to be presented in the context view UI.

Example 1: The file views in the IDE may come with a huge amount of files, organized in deep hierarchical structures. On the other hand it is expected, that typically only a fraction of them will be a part of a context. Those context relevant files will be listed in the Context View and their projects will be the root nodes of the whole structure. It also seems to be useful to have provided an easy way to remove some files from the context.

Example 2: The list of breakpoints in the debugger breakpoints view will be identical with the list of breakpoints given by the active contexts. Adding and removing breakpoints from the native debugger view adds or removes them from the context. A dedicated breakpoint list in the context UI would only redundantly mimic what already is provided in the debugger UI.

TODO: to be reconsidered if the context view should provide at least some kind of a brief info about elements like mentioned in Example 2 (if nothing else then for completeness sake?), or if the view should come only with such type of elements in case of which it really matters (example 1).

Automatically adding or removing context elements

There is an active task/context in the IDE. During his work the user accesses various resources or changes some IDE settings. Such actions are automatically monitored and tracked in the task context.

Examples: A file becomes part of a context when it is opened or changed by the user. A breakpoint becomes part of a context when it is created and removed from the context when it is deleted by the user.

Manually adding or removing context elements

There is an active task/context in the IDE. The user realizes that some irrelevant elements became part of the context, so he opens the context view UI and removes them.

Example: While working on a task the user opened a lot of files, but some of them weren't really interesting in the currently activated tasks scope. The user decides to clean up the polluted context and removes those files from it.

TODO: is there any real life scenario giving as the motivation for manual add of elements into a context?

Cloning a context

The user wants to reuse a context in another task, so he

  • either switches from an active task and takes over the context
  • or he explicitly clones the context from some another task

Example: The user typically works on two distinct groups of projects. When activating for the first time a task witch is related either to one or another, he copies an already existing context into the newly activated task.

TODO: Having a template task for e.g. various project groups sounds a bit like a clumsy workaround and a regression to what the project groups provide today. Said with other words, a project grop can be currently reused for more then one task. With contexts the user to every time he starts a new task to setup the list of projects, or copy them over from another task. The result could be that many users will reopen the necessary projects every time a task is activated, just because it is more streamlined. This has to be thought trough ...

Maybe it would be enough to have some simple question dlg/wizard on first ctx activation to specify what has to become part of the new context. How much is it to be expected that the user will wildly switch between various setups?

TODO

  • Sharing a context
  • Attaching a context
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