Datasources

Zeppelin application works from a data source for the predefined KPIs. This can be fed from local data files or through a connection to Jira.

As for the data files, an unlimited number of them can be used. Each desktop can have its own source/repository. Select which one to use via the Connection | Connector | DatasourceInterface -> file name

The content of the data file must be delimited by TABS (and have the extension *.tsv).

The application provides three examples (FULL) with real data that can be used to create your own data source (for example via a spreadsheet). Certain fields are required (see Data Sources), and custom fields are allowed.

In the case of the Jira server plugin version, you do not need to configure the connection (it runs within the web browser session), but in the case of the Jira Cloud version it is necessary to indicate in the Preferences | link:

• Jira server address: method (http/https), server name[:port][/path]

• Jira user to establish the connection to the Jira server

• Jira password (it is encrypted)

Depending on whether it is the first time entering the application, a default project for the user will be determined. The procedure allows the application to estimate the project (by reading the KPIs data for the projects of which the user is the leader and considering those with the highest volume), or allowing the user to select it from the list of their projects. This value can always be edited from Preference | Explorer.

Another important setting in this category is Max number of months (0 all) for reading Jira project data.

All the configuration can be saved together with the image so that it is not necessary to repeat this process later. The user can edit the Story, create new Morphs with Signals using the existing KPIs or new ones created by the user using the domain language.

Important Application Files

bundles

prefs

prototypes

uploads

configuration.json

kpi.json

data_ind.tsv

data_mov.tsv

data_soft.tsv

index.html

zeppelin.kpi

zeppelin.configuration

zeppelin.image

Steps

In summary, a possible application lifecycle flow could be:

Setup

• Complete Preferences

• Generate your own data file (to know the application three complete examples are provided)

• Complete the Maps

Explore

• Do a Scan or open a Morph from the desktop menu

• Use the Signals tool

• Analyze data and system activity from the Halo menu of a Morph

Analyze

• Add data pages to History

• Write down the data

• Establish baselines and process limits for monitoring

• Add another type of pages to the Story (text, morphs, etc)

• Argue using statistical tools and activity patterns

Share

• History or pages as files

• Publish an image to web (local network)

Develop

• Create KPIs if necessary (in many cases it will not be necessary, a Library with typical indicators is provided)

• Create more sophisticated scripts using domain specific language, which can be used as KPI sources or directly reusable as bundles from the menu

• Create multiple desktops (each can have its own data source) for different purposes

• Create multiple files with different Stories (accessible as shortcuts or from the menu)

Learn about the User Interface

The user interface consists of the following elements:

• General Menu bar: at the top of the screen, displays a menu "Improvekit" system (icon)

• Improvekit Menu: This menu allows you to query the current system version,  connect / disconnect to the repository of measurements and exit from the application

• Balloon Help menu options: is displayed when the cursor is positioned a pair of seconds in a menu and report briefly on the function performed by this option

• Context menu: accessed by right-clicking certain element positioned on the interface. Menu options are always available also from the main menu bar.

• Color of tools: allow access by clicking the main application tools.

• Desktop: work area where direct links to indicators and files (local and remote) can be created. The Desktop can be saved in the state so that it restores its current state when re-entering the application through the menu options "Improvekit | Save, and Improvekit | Save and exit"

• Multiple desktops/repositories: you can create new virtual desktops, sharing connectivity with a repository or each with its own connectivity (for example, one desktop working with data in local files and another directly connected to Jira Cloud)

• Morphs : to create a graphic object on the desktop with any indicator you access a repository directly manipulating the same at both visual level and its essential behavior ( using the definition of the indicator specification language IHDSL high level). This lets you have your indicators on your desk and compose information extremely agile. These indicators can be updated by a click ( option menu on your desktop ) or added to a Dashboard (Story) for data signal analysis in depth . You can access all control by targets innovative menu "halo" with the right mouse button

Keys

Note: Cmd key is the Command key on Mac and MS-Windows Alt

Morphs

Being able to "see inside" the software also implies an interactive design in which the code is separated as little as possible from its computational execution result. Once the code is visible and understandable in this way, it's a short step to make it reusable. So how can this transparency be achieved? In a fully object-oriented system, one way is to implement a "raise the hood" command, available on each input or output object, which displays an interface for browsing or editing that input and output object, as well as the objects it contains. it is composed of and the objects to which it is connected. Zepplin already has this feature, in the form of a "halo"

The halo can be used for graphical operations, but also to open Viewers, to explore and change the IHDSL code that describes an object's behavior.

Playing with Morphs is crucial to the development of interactive systems, for these reasons, most of which are particular forms of tuning:

1. Find the rules that govern the behavior of the algorithm (parameters IHDSL+ctrl),

2. Develop the "trends" or archetypes of the system,

3. Intuitively learn the "language" and capabilities of the algorithm by:

   1. expose the potentials of algorithm dynamics,

   2. making evident the place of the algorithm within the system, highlighting the interactions and structural limitation

   3. c. provide a real-time response to user actions

4. Produce computational, technological, and commercial meaning simultaneously (reducing ambiguity, producing successful boundary objects, and thus aiding interdisciplinary attunement),

5. Make the user feel more comfortable and empowered,

6. Incorporate synthetic and analytical approaches to problem solving, and

7. Get the technologist's interpretation out of the loop.

These Morphs, then, are borderline objects that embody a language to create meaning between the business and the technologist, and the user and the computer, and perhaps less necessarily, the technologist and the computer. (There is also scope for these tools to become boundary objects for other communities, such as other stakeholders and technologists, engineers, and managers.)