O D Enacheanu

N Riu

Retière

Half-order modelling of electrical networks Application to stability studies

The fractional order systems has been used successfully to model in frequency domain the development of induced currents in electric machines, especially in the dampers or massive parts of large synchronous machines. The objective of this work consists in extending the field of application of fractional order models for small signal stability studies of an electrical network.

INTRODUCTION

For several years, a very close attention has been paid to the study of the electrical networks in order to improve their sizing, their quality, their safety and their performances. Indeed, the electrical networks become more and more complex, including an increasing number of power electronics converters, which are used as interface or control devices (Barruel, 2005, Wildrick et al., 1993).

To bring solutions to the problems caused by this new context of electrical networks is a difficult task. For example, an accurate modelling over a large frequency range is delicate and generally leads to the simulation of huge systems, with a great number of parameters (Kundur, 1994). As a result, reduction techniques of model size are often required. Several works on the reduced modelling of electrical machines concern the use of the fractional order derivation (Riu, 2001). They lead to the development of models which are accurate and of reduced order. The resulting models are especially dedicated to dynamic studies of power networks.

In this paper, the authors have focused on the study of small signal stability of an on-board electrical network or any electrical systems in which the synchronous machine are modelled by half-order systems. We will compare t wo classical stability methods commonly used in power systems studies, one based on modal approach and another based on Nyquist criterion. For both approaches, the synchronous machine is modelled using a non integer order system.

HALF -ORDER MODELLING OF A SYNCHRONOUS MACHINE

Non integer order systems

The non-integer order derivation is applied since several years in many scientific fields as rheology, chemistry, signal processing, control or electromagnetic computation. It is used for an accurate modelling of some physical phenomena like diffusion, fractal structures ( Oldham, et al., 1974) or distributed parameter systems which are represented by partial differential equations. It is also the base of a particular technique of robust control (Oustaloup, 1995).

A non-integer order system is characterized by the presence of a non-integer order operator. In frequency domain, the system is characterized by a frequency power law. For instance, half-order systems vary with the square root of frequency.

Non integer order model of synchronous machine

It has been shown that the diffusion phenomena in alternator damping bars ( Fig. 1) can be modelled by a half-order resistive system. The impedance of a rectangular bar can be expressed as a half-order system (Retière et al., 1999):

H 0 J, E h L b e H 0 J, E h L b e H 0 J, E h L b H 0 J, E h L b e H J,
o o resistive j R Z ω ω + = 1 2 1 (1)
where 3 shows the relevance of this model compared with the analytical expression of the impedance (Alger, 1970):

e h L R b o ⋅ ⋅ = σ and 2 1 h o ⋅ ⋅ = µ σ ω Fig.
( ) α α th R Z o ana ⋅ = with 2 2 h jωσµ α = (2)
In the same way, it has been shown that the impedance characterising a solid ferromagnetic piece ( Fig. 2) can be expressed as a half-order inductive system: In order to take into account the frequential effects of the induced currents in the synchronous machine, a new equivalent circuit in the Park reference frame is established from the following physical considerations:

• no induced currents expand in the armature windings for frequencies lower than 1 kHz: it is modelled by a resistance (r s ) and an inductance (l s );.

• the inductance l ad , corresponding to the stored energy in the air gap, is supposed to be constant versus frequency;

• due to the development of induced currents in the massive parts of the rotor, an "inductive" half-order impedance is added in parallel to l ad :

q d q d q d j L j Z / 1 / 1 / 1 1 ) ( 2 1 ω ω ω ω + =
• eddy currents are neglected in the excitation winding, which is therefore modelled by a resistance r f and an inductance l f , both constant versus the frequency;

• a constant inductance l 12d is associated to the mutual field between the exc itation and the damper windings;

• the damper windings are modelled by a "resistive" halforder impedance:

q d q d q d j R Z / 2 / 2 / 2 1 ) ( 2 1 ω ω ω + =
• .the effect of speed variation on stator voltage are given by ω•λ d in d axis and ω•λ q in q axis. The resulting "half-order" equivalent circuit of a synchronous machine in the d-and q-axes is shown in (Fig. 4) and (Fig. 5) for steady-state conditions.

It should be noted that -contrary to integer models of such alternators-each parameter has a physical signification. These equivalent circuits have been identified and compared to traditional integer models ( Riu, 2001); their principal properties relate to their compactness (a model of a non integer order includes twice less parameters than a traditional integer model), their precision over a large frequency range for this kind of system (until approximately 1000 Hz) and their physical signification as each parameter can be linked directly to geometrical dimensions and physical characteristics of the machine.

V f r sd l sd l ad r f l f V d Z 1/2 1d Z 1/2 2d l 12d ω q V q Z 1/2 1q l aq l sq r sq ω d Z 1/2 2q l 12q

SMALL SIGNAL STABILITY ANALYSIS OF A NON-INTEGER ORDER SYSTEM

For an alternator, it is possible to study his voltage stability, speed (or frequency) stability and rotor angle stability (Kundur, 1994):

• voltage stability refers to the ability of a power system to maintain voltage at all buses in the system after a perturbation from a given initial condition;

• frequency stability refers to the ability of a power system to maintain frequency following a severe system disturbance resulting in a significant imbalance between generation and load;

• rotor angle stability refers to the ability of synchronous machines to remain in synchronism after being subjected to a disturbance.

Disturbances may be small or large, leading to the analysis of small-signal or large-signal stability. In this article , the authors are just interested in the study of small-signal voltage stability of an electrical system. The small-signal conditions enable us to work directly on a linearized model of the system around the operating point.

As mentioned above, we have been interested in the stability study of an electrical network. Sources of instability are related to interactions between devices connected to the network (electrical motors, generators, power converters, filters). For stability aspects, power converters are crucial devices. Indeed, their control mode is so that they behave as constant power loads. From a small-signal point of view, it means that a power converter can be represented by a negative resistance, which is typical of an unstable load.

In this paper, a basic power system as described in figure 6 is analyzed. It includes a synchronous generator and a constant power load. The alternator is supposed driven by a constant speed turbine. For simplicity purpose, the voltage alternator is not controlled. This simplification does not change the relevancy of the methodology given here after.

Frequency approach for stability analysis

Stability analysis of an electrical system can be based on an impedance method ( Sudhoff et al., 2000). The most straightforward application of the impedance method to power systems is called " Middlebrook criterion" (Middlebrook, 1979). According to this criterion, a system is stable if the Nyquist contour of the ratio Z source /Z load stays within the unit circle, where Z source is the alternator impedance and Z load , the constant power load impedance (Fig. 6). The transmission line is included in the source impedance. All these impedances are analytically calculated using Thevenin theorem. The synchronous machine being modelled by two equivalent half-order circuits, one in d-axis and the other in q-axis, we need to apply the Middlebrook criterion in both axes.

Z source Z load

V source V load i s i l V Fig. 6. Thevenin equivalent circuit of the studying system.

Modal approach in stability analysis

From the electrical equation given by the equivalent halforder circuits (Fig. 4 and Fig. 5), we can build a generalised state system including the non integer order derivation of state variables. This system equation can be written as follows (Oustaloup, 1995):

[ ] ( ) [ ] [ ] [ ] [ ] u B x A x n ⋅ + ⋅ = (4)
where n is a real number, [A] the state matrix, [x] the state vector, [B] the input matrix and [u] the input vector.

If n is equal to unity, we find the well-known expression of a classical state system. From this relation, it is possible to calculate the eigenvalues and their associated vectors (right and left vectors). For a non-integer order system with a fractional order between 0 and 1, the small signal stability condition is given b y the following relation ( Matignon, 1996):

( ) 2 arg π λ ⋅ ≥ n i ( 5
)
This result is well-known for n=1. Its geometric translation for n=1/2 is given in Fig. 7.

Application to electric power systems

Frequency approach. Considering a power system with a constant power load and a synchronous machine modelled using half-order systems in d-and q-axis, the Middlebrook criterion is applied. According to this criterion the transfer function T of the system is given by: ( )

load source Z Z s T + = 1 (6) Instable Stable Re Im 2 π ⋅ n 2 π ⋅ n Stability limit
Fig. 7. Stability/instability area for a half-order system.

Modal approach. For the same power system, a generalised state system including the non integer order derivation of state variables is calculated from the differential equations describing the system :

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )                          + + ⋅ ⋅ - - + + ⋅ ⋅ - ⋅ ⋅ - = + + ⋅ ⋅ - ⋅ ⋅ - ⋅ - = + + ⋅ ⋅ - ⋅ ⋅ - ⋅ - = + + + ⋅ ⋅ - ⋅ ⋅ - ⋅ - = + + + ⋅ ⋅ - - + + + ⋅ ⋅ - ⋅ ⋅ - = + ⋅ ⋅ - + + + ⋅ ⋅ ⋅ - ⋅ - ⋅ - = + ⋅ ⋅ - + + + ⋅ ⋅ - ⋅ ⋅ - ⋅ - =
q q q q aq q q q aq q q q q q aq q q q q q q q aq q q q q 7), the generalised state system can then be written as :

d d f d ad d d d d d d f d d ad d d f d ad d d d f d d d f d ad d d d d d d f d d d f d ad f f f f f i i i s l i i i s l i s L i i i s l i s l i r i i i s l i s l i r V i i i i s l i s l i r V i i i i s l i i i i s l i s L i i s l i i i i s l i s R i R i i s l i i i i s l i s l i r V 2 1 2 / 3 1 2 1 1 1 2 1 2 2 2 2 2 1 2 1 2 1 2 / 3 1 2 1 1 1 2 12 2 1 2 2 / 1 2 2 2 2 2 12 2 1 0 0 0 0 ω ω ω (7) Introducing 2 1 / 1 q d Z and 2 1 / 2 q d Z into (
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )                            ⋅ + ⋅ + ⋅ + ⋅ + ⋅ + ⋅ = ⋅ + ⋅ + ⋅ + ⋅ = = ⋅ + ⋅ + ⋅ + ⋅ = = ⋅ + ⋅ + ⋅ + ⋅ + ⋅ + ⋅ + ⋅ + ⋅ + ⋅ = ⋅ + ⋅ + ⋅ + ⋅ + ⋅ + ⋅ + ⋅ = = ⋅ + ⋅ + ⋅ + ⋅ = = ⋅ + ⋅ + ⋅ + ⋅ + ⋅
q q q d f d f d f d V x a x a x a x a x a x V x a x a x a x x x V x a x a x a x x x V V V x a x a x a x a x a x a x V V x a x a x a x a x a x x x V x a x a x a x x x V x a x a x a x a x x x λ η γ ϕ φ ε δ χ β α (8)

Comparison between modal and frequency approaches

The studied system is composed by a (1101 MVA, 22 kV, 60 Hz) synchronous machine and a constant power load of 650 MW.

In Fig. 8.a and 8.b, we have represented the frequency evolution of the d-axis operational inductance using SSFR tests given in (Canay, 1993), as well as inductances resulting from the classical and fractional modelling. It should be also specified that implicit half order systems has been approximated by explicit half-order systems , thanks to the induced simplifications to construct the generalized statespace system.

Middlebrook criterion Middlebrook criterion

Real axis

Imaginary axis Fig. 9. System poles given by modal analysis and Theveninbased impedance approach In Fig. 10, poles are also given for an equivalent integerorder model of the system (Riu, 2001). Both cases show that the system is unstable because poles are located in the unstable area. This is due to the constant power load. Using the Middlebrook criterion, e.g. by examining the Nyquist contour of the transfer function Z source /Z load , we can also show that the system is unstable if the load is a constant power load. If the load is a constant impedance one, the system is stable. Nyquist diagrams are presented in (Fig. 11) for d-axis and in (Fig. 12) for q-axis. In this paper, we have modelled a synchronous machine using non-integer order systems . These systems allowed to carry out equivalent circuits in d -and q -axis which are accurate and compact over a large frequency range. This modelling has been used for the stability study of a system connecting a synchronous machine and a constant power load.

Real axis

It has been showed that by generalizing classical integer order methods for stability study (i.e. frequency approach by Nyquist criterion and modal approach), it w as possible to predict the stability.

Prospects of this work concern the computation of participation factors. These factors should give us an idea of the links between dynamic performances of the system and the constructive parameters of the systems. REFERENCES

  Fig. 1. Representation of a damper bar.

Fig. 3 .

 3 Fig. 3. Comparison between the analytical and half order approximation of the damper bar impedance.

Fig. 4 .

 4 Fig. 4. Synchronous machine, direct axis equivalent halforder circuit

  Fig. 8.a. D-axis operational inductance identification.

  Fig. 8.b. Q-axis operational inductance identification.

Fig. 9

 9 Fig.9represents the poles of the system calculated from the state-space system and the transfer function T. They are of course strictly superposed.

  Fig. 10. Poles migration in case of instability.

  Fig. 11. d-axis Nyquist diagram :

. Influence des charges non linéaires sur le comportement et le dimensionnement d'un réseau d e bord d'avion, Phd thesis in French. Wildrick, C.M., L ee F.C., C ho B.H., Choi B., (1993). A method of defining the load impedance specification for a stable distributed power system, IEEE PESC, Seattle, USA Kundur, P., (1994). Power system stability and control, Electric Power Research Institute, Mc Graw-Hill. Riu, D., (2001). Modélisation des courants induits dans les machines électriques par des systèmes d'ordre un demi, Phd thesis in French. Oustaloup A., (1995). La dérivation non entière, Hermès, Paris . Oldham, K.B., Spanier J., (1974). The fractional calculus -Theory and applications and differentiation and integration to arbitra ry order, Academic Press, New-York. Retière, N., Ivanes, M., (1999). An introduction to electric machine modelling by systems of non integer order. Application to double-cage induction machine, IEEE Trans. Energy Conversion, Vol. 14, pp. 1062-1032. Sudhoff, S.D., Glover, S.F., Lamm, P.T., (2000). Admittance space stability analysis of power electronic systems, IEEE Transaction on aerospace an electronic systems, Vol. 36, No. 3, pp. 965-973. Middlebrook, R.D., (1979). Input filters considerations in design and applications of switching regulators, IEEE Industry Applications Society Annual Meeting, Chicago. Canay, I.M., (June 1 993) Determination of the model parameters of machines from the reactance operators xd(p) and xq(p), IEEE Trans. on Energy Conversion, Vol. 8, No. 2, pp. 272-279. Matignon, D., (1996). Stability results for fractional equations with applications to control processing, Computational engineering in systems applications, IMAC, IEEE-SMC, Vol. 2, pp. 963-968.


Julien Gori
email: jgori@lri.fr

Han L Han
email: han.han@lri.fr

Michel Beaudouin-Lafon

FileWeaver: Flexible File Management with Automatic Dependency Tracking

Keywords: File system, Dependency management, Version management, Workflows CCS Concepts, Human-centered computing → Graphical user interfaces, Interaction techniques

Knowledge management and sharing involves a variety of specialized but isolated software tools, tied together by the files that these tools use and produce. We interviewed 23 scientists and found that they all had difficulties using the file system to keep track of, re-find and maintain consistency among related but distributed information. We introduce FileWeaver, a system that automatically detects dependencies among files without explicit user action, tracks their history, and lets users interact directly with the graphs representing these dependencies and version history. Changes to a file can trigger recipes, either automatically or under user control, to keep the file consistent with its dependants. Users can merge variants of a file, e.g. different output formats, into a polymorphic file, or morph, and automate the management of these variants. By making dependencies among files explicit and visible, FileWeaver facilitates the automation of workflows by scientists and other users who rely on the file system to manage their data.

INTRODUCTION

While some users can manage their entire workflow within a single application or integrated application suite, many knowledge workers, such as scientists, must use several specialized tools that are not designed to dialog with each other. For example, Oleksik et al. [START_REF] Oleksik | Beyond Data Sharing: Artifact Ecology of a Collaborative Nanophotonics Research Centre[END_REF] describes how researchers use a mix of standard office productivity tools and specialized tools for experimental protocols and data analysis, while Zhang et al. [START_REF] Zhang | How Do Data Science Workers Collaborate? Roles, Workflows, and Tools[END_REF] list up to 13 different categories of tools used by data scientists. Specialized tools typically load and save information in proprietary and/or binary data formats, such as Matlab 1 .mat files or SPSS 2 .sav files. Knowledge workers have to rely on standardized exchange file formats and file format converters to communicate information from one application to the other, leading to a multiplication of files.

Moreover, as exemplified by Guo's "typical" workflow of a data scientist [8, Fig. 2.1], knowledge workers' practices often consist of several iterations of exploratory, production and dissemination phases, in which workers create copies of files to save their work, file revisions, e.g. to revise the logic of their code, and file variants, e.g. to modify parameter values. Jensen et al. [START_REF] Jensen | The Life and Times of Files and Information: A Study of Desktop Provenance[END_REF] observed that short-and long-term pauses can cause users to forget about the organization of their files when they need to access them. Neither the file system nor file navigation tools are designed to track the relationships between files nor the histories of files, offering little support to knowledge workers for managing the numerous files and associated workflows that their work requires. Software designed to capture file provenance [START_REF] Muniswamy-Reddy | Provenance-aware storage systems[END_REF][START_REF] Murta | noWorkflow: capturing and analyzing provenance of scripts[END_REF] addresses a similar issue by capturing metadata describing the origin of the files as well as all the actions that are performed on it and the actors who perform them. However, we do not know if this fine-grained approach is adapted to the needs of knowledge workers.

In this paper, we first investigate how and with which tools knowledge workers manage their information. We interviewed 23 scientists -an extreme example of knowledge workerswho were not specifically trained in software engineering nor computer science and identified six types of problems they face. Based on these findings, we describe FileWeaver, a system that automatically detects dependencies among files, tracks their history, and lets users interact directly with the graphs representing these dependencies and version history. Changes to a file can trigger recipes, either automatically or under user control, to keep the file consistent with its dependants. We describe FileWeaver's features and illustrate how they address some of the issues identified in the user study. We conclude with an analysis of FileWeaver using Green's cognitive dimensions [START_REF] Green | Cognitive Dimensions of In Proceedings of the Fifth Conference of the British Computer Society, Human-Computer Interaction Specialist Group on People and Computers V[END_REF] and directions for future work.

RELATED WORK

We review previous research in three main areas: the issues related to information silos, i.e. the fact that digital information tends to be trapped in proprietary files formats and closed systems; the practices and workflows used by scientists in their data analysis tasks; and the studies and tools addressing the management of file relationships.

Information Silos

Previous work has identified the difficulties that users encounter with the rigid hierarchical organization of current file systems [START_REF] Paul Dourish | Presto: An Experimental Architecture for Fluid Interactive Document Spaces[END_REF][START_REF] Bondarenko | Documents at Hand: Learning from Paper to Improve Digital Technologies[END_REF][START_REF] Ravasio | In Pursuit of Desktop Evolution: User Problems and Practices with Modern Desktop Systems[END_REF] and the information fragmentation created by information silos [START_REF] Ravasio | In Pursuit of Desktop Evolution: User Problems and Practices with Modern Desktop Systems[END_REF][START_REF] David | Data unification in personal information management[END_REF]. In a study of users' desktops, Ravasio et al. [START_REF] Ravasio | In Pursuit of Desktop Evolution: User Problems and Practices with Modern Desktop Systems[END_REF] reported the interviewees' frustration with the fragmentation of information across files and most interviewees expressed the need to have their information linked together. The Placeless system [START_REF] Paul Dourish | Presto: An Experimental Architecture for Fluid Interactive Document Spaces[END_REF] partially addressed these issues by letting users create and manage their own document properties. Karger [START_REF] David | Data unification in personal information management[END_REF] proposed three approaches to address information fragmentation: grouping (including tagging), annotating, and linking; and showed that linking related information can support users orienteering behavior [START_REF] Teevan | The Perfect Search Engine is Not Enough: A Study of Orienteering Behavior in Directed Search[END_REF].

Research on scientists' work practices further highlights these issues. Oleksik et al. [START_REF] Oleksik | Beyond Data Sharing: Artifact Ecology of a Collaborative Nanophotonics Research Centre[END_REF] studied the artifact ecology of a research center and found that scientists used multiple computing applications to create information artifacts that are locked into applications, making it difficult to reuse content and get a unified view of the related research material. Their follow-up study [START_REF] Oleksik | Towards an Information Architecture for Flexible Reuse of Digital Media[END_REF] revealed the need to support three types of links: inheritance (source document), spatial proximity (spatial layout), and explicit links (resources and notes). Tabard et al. [START_REF] Tabard | From Individual to Collaborative: The Evolution Prism, a Hybrid Laboratory Notebook[END_REF] studied lab notebooks and found that biologists work with a complex web of interrelated references in both the physical and digital worlds that they keep in their head, and that they struggle to map this structure into a single organizational form.

Since these studies were conducted seven to twenty years ago, we wanted to know if scientists still struggled with managing their information. We are particularly interested in how current tools support or hinder knowledge management and sharing in their daily tasks.

Data Analysis Tasks and Workflows

Data analysis and sharing is an essential part of scientific discovery [START_REF] Oleksik | Beyond Data Sharing: Artifact Ecology of a Collaborative Nanophotonics Research Centre[END_REF]. The iterative and exploratory nature of data analysis [START_REF] Jia | Software tools to facilitate research programming[END_REF] tends to produce numerous manually versioned scripts and output files [START_REF] Guo | BURRITO: Wrapping Your Lab Notebook in Computational Infrastructure[END_REF]. Computational notebooks combine code, visualizations and text, bringing fragmented but related information into a single document [START_REF] Rule | Exploration and Explanation in Computational Notebooks[END_REF]. Scientists are rapidly adopting this new medium to document and share exploratory data analyses [START_REF] Shen | Interactive notebooks: Sharing the code[END_REF]. Researchers have built tools for computational notebooks to support various activities such as informal and rapid version control [START_REF] Beth Kery | Variolite: Supporting Exploratory Programming by Data Scientists[END_REF], re-finding of past analysis choices [START_REF] Beth Kery | Towards Effective Foraging by Data Scientists to Find Past Analysis Choices[END_REF], easy navigation [START_REF] Rule | Aiding Collaborative Reuse of Computational Notebooks with Annotated Cell Folding[END_REF] and managing messes [START_REF] Head | Managing Messes in Computational Notebooks[END_REF].

However, building these tools within computational notebooks does not fully solve the problem: studies show that users of computational notebooks need to access diverse tools [START_REF] Zhang | How Do Data Science Workers Collaborate? Roles, Workflows, and Tools[END_REF] and combine them with other tools and documents [START_REF] Rule | Exploration and Explanation in Computational Notebooks[END_REF][START_REF] Chattopadhyay | What's Wrong with Computational Notebooks? Pain Points, Needs, and Design Opportunities[END_REF]. A survey [START_REF] Zhang | How Do Data Science Workers Collaborate? Roles, Workflows, and Tools[END_REF] of data scientists' collaborative practices reported 13 high-level categories of tools, including code editors, e.g. Visual Studio Code, computational notebooks, e.g. Jupyter Notebook, spreadsheets, data analysis tools, e.g. SPSS, document editing tools, e.g. LaTeX, and presentation software, e.g. Microsoft PowerPoint. Rule et al. [START_REF] Rule | Exploration and Explanation in Computational Notebooks[END_REF] found that "individual notebooks rarely tell a story by themselves but are routinely combined with other notebooks, emails, slides, and ReadMe". Furthermore, their interviewees "even transferred outputs of the analysis to an entirely different medium (e.g. slides, word processing document) for easier review."

These studies suggest that scientists use a variety of tools in their data analysis and sharing process. We are interested in how they track the inter-connections between different documents and files in this process and why they choose to create multiple documents in the first place.

File Relationships

Previous research has explored file relationships to devise new ways to organize digital content, including using metadata [START_REF] Paul Dourish | Presto: An Experimental Architecture for Fluid Interactive Document Spaces[END_REF], tagging [START_REF] Oleksik | Lightweight Tagging Expands Information and Activity Management Practices[END_REF] and activity-based computing [START_REF] Salmon | Perspective: Semantic Data Management for the Home[END_REF][START_REF] Voida | It Feels Better than Filing: Everyday Work Experiences in an Activity-Based Computing System[END_REF]. We focus here on provenance [START_REF] Jensen | The Life and Times of Files and Information: A Study of Desktop Provenance[END_REF] and linking [START_REF] Tabard | PageLinker: Integrating Contextual Bookmarks within a Browser[END_REF], which are particularly relevant to representing relationships among files.

Provenance

Jensen et al. [START_REF] Jensen | The Life and Times of Files and Information: A Study of Desktop Provenance[END_REF] studied the provenance of files on desktops and showed that it helped reveal the work patterns of knowledge workers. Several tools are based on the idea of sourcing file relationships for version management [START_REF] Siân | Exploring New Metaphors for a Networked World through the File Biography[END_REF][START_REF] Karlson | Which Version is This? Improving the Desktop Experience within a Copy-Aware Computing Ecosystem[END_REF] and file retrieval [START_REF] Craig | Connections: using context to enhance file search[END_REF][START_REF] Ghorashi | Leyline: Provenance-Based Search Using a Graphical Sketchpad[END_REF][START_REF] Stumpf | The use of provenance in information retrieval[END_REF]. For example, Connections [START_REF] Craig | Connections: using context to enhance file search[END_REF] uses file relationships to enhance file searches; Leyline [START_REF] Ghorashi | Leyline: Provenance-Based Search Using a Graphical Sketchpad[END_REF] integrates provenance into the query composition and result presentation of a search system; and TaskTrail [START_REF] Stumpf | The use of provenance in information retrieval[END_REF] tracks file provenance through user events such as copy-paste and save-as, and represents it in a graph view to assist users in re-finding documents.

Karlson et al. [START_REF] Karlson | Which Version is This? Improving the Desktop Experience within a Copy-Aware Computing Ecosystem[END_REF] describe a system that tracks copy relationships among files, helping users to manage their versions. They introduce the 'versionset', a set of files that represent a user's concept of a document and found that file format is an important element of the user's conceptual model. Linkdley et al. [START_REF] Siân | Exploring New Metaphors for a Networked World through the File Biography[END_REF] developed the 'file biography' to encompass the provenance of a file and its propagation. Commercial user interfaces for version control systems such as Gitkraken 3and SourceTree4 represent file revisions in a time-based tree visualization 5 , but these tools are designed primarily for coordinating work among programmers. Prior studies have found that scientists rarely use version control systems [START_REF] Beth Kery | Variolite: Supporting Exploratory Programming by Data Scientists[END_REF][START_REF] Perez | What's Wrong with Git? A Conceptual Design Analysis[END_REF] and that knowledge workers mostly use manual versioning [START_REF] Karlson | Which Version is This? Improving the Desktop Experience within a Copy-Aware Computing Ecosystem[END_REF][START_REF] Han | Textlets: Supporting Constraints and Consistency in Text Documents[END_REF] because they find version control systems too complex.

We find two limitations to these systems: They require users to explicitly specify relationships among files, and the relationships are presented as non-interactive graphs. We are therefore interested in improving both automation to infer file dependencies and direct interaction to provide more user control.

Linking

Tabard et al. [START_REF] Tabard | PageLinker: Integrating Contextual Bookmarks within a Browser[END_REF] take a different approach to support web navigation by automatically linking web pages together according to user actions. Software development tools such as webpack 6generate a dependency graph by analyzing source code, but do not visualize nor let users control the resulting graph.

Our goal is to design a lightweight tool for knowledge workers to keep track of file dependencies and manage the various versions and formats of their files. Our target audience are users who manage information across files of various types and process them through tools such as scripts and compilers.

FORMATIVE STUDY: INTERVIEWS WITH SCIENTISTS

We conducted critical object interviews [START_REF] Mackay | Using video to support interaction design[END_REF] to better understand how scientists, who can be considered "extreme" knowledge workers, manage complex research information.

Participants: We interviewed 23 scientists (7 women, 16 men): six professors, four researchers, four Ph.D. students, five research engineers, three post-docs, and one research associate. The research topics include neuroscience, mathematics, chemistry, physics, biology and computer science.

Procedure: All interviews were conducted in English by the second author and lasted 45-60 minutes each. We visited the participants in their labs and asked them to show us the tools, e.g. notebooks, that they use to keep track of their research information. Based on the artifacts they showed us, we asked them to describe a recent, memorable event, either positive or negative, related to using that artifact. We then asked about their work practices based on these events and artifacts.

Data Collection: All interviews were audio recorded and transcribed. We also took photos and hand-written notes.

Data Analysis: We analyzed the interviews using reflexive thematic analysis [START_REF] Braun | Reflecting on reflexive thematic analysis[END_REF]. We generated codes and themes both inductively (bottom-up) and deductively (top-down), looking for breakdowns, workarounds and user innovations. Two coders (including the interviewer) conducted the analysis. They grouped codes into larger categories, discussed any disagreements and rechecked the interview transcripts to reach a shared understanding. They arrived at the final themes after two iterations.

RESULTS AND DISCUSSION

We used the concept of information substrate to conduct the thematic analysis. Beaudouin-Lafon [START_REF] Beaudouin-Lafon | Towards Unified Principles of Interaction[END_REF] describes substrates as computational media that hold digital information, possibly created by other substrates, manage constraints and dependencies, react to changes in both the information and the substrate, and generate information consumable by other substrates. Maudet et al. [START_REF] Maudet | Beyond Grids: Interactive Graphical Substrates to Structure Digital Layout[END_REF] analyzed the constraints and rules that graphical designers manage in their heads and introduced digital tools that explicitly support these substrates. We follow a similar approach by identifying the types of substrates currently used by scientists in order to inform the design of more appropriate ones. We extend the original concept of substrate to cover both physical and digital artifacts.

Based on these concepts, the thematic analysis led to six primary themes related to: using multiple substrates; transferring information across substrates; keeping information "just in case"; finding and re-finding; iterating the producecommunicate cycle; and expressing file relationships.

Taking Advantage of the Characteristics of Substrates

All participants take advantage of the characteristics of different types of information substrates to manage their information. For example, they use paper as a thinking and reasoning tool because free-hand drawing enables rich representations, flexible layout and better memorization. This is consistent with prior studies on the advantages of paper [START_REF] Sellen | Paper as an Analytic Resource for the Design of New Technologies[END_REF][START_REF] Hara | A Comparison of Reading Paper and On-Line Documents[END_REF][START_REF] Mackay | Is Paper Safer? The Role of Paper Flight Strips in Air Traffic Control[END_REF][START_REF] Sellen | The Myth of the Paperless Office[END_REF].

Most participants (20/23) use at least one blackboard or whiteboard in their office or in meeting rooms. These boards offer a large working space for free-hand sketching and writing, supporting fluid collocated collaboration [START_REF] Rønby Pedersen | Tivoli: An Electronic Whiteboard for Informal Workgroup Meetings[END_REF][START_REF] Tang | Supporting Transitions in Work: Informing Large Display Application Design by Understanding Whiteboard Use[END_REF].

Five participants with experimental science training also keep a physical lab notebook. This notebook follows a chronological order and makes it easy to switch between structured and free-form information. Participants create links to keep related information in context by noting down file names or sticking print-outs on the relevant pages. Participants also have at least one personal notebook for "purely temporal information" (P15). These personal notebooks are less clean and structured than the "official" lab notebook. Participants transfer the important information to the lab notebook.

Similar to the analysis of biologists' work practice [START_REF] Tabard | From Individual to Collaborative: The Evolution Prism, a Hybrid Laboratory Notebook[END_REF], these results suggest that the nature of information being distributed among different artifacts such as paper, whiteboard and lab notebook, is driven by their unique characteristics.

Transferring Information Across Substrates

From a first raw idea on paper to a well-written article, participants continuously structure their ideas over time as a project unfolds. We found that the process of transferring information from one substrate to another is a necessary cognitive process where participants review, rethink and re-evaluate their ideas.

P9 described how he worked with a colleague on an idea by writing on the blackboard; copying it onto paper in a cleaner version; going back and forth between blackboard and paper several times until it was mature enough to write it in LaTeX. He explained: "When I copy, I am not just copying. I try to understand it of course... We also fix errors when we transfer".

Seven participants reported taking whiteboard photos during meetings to persist information digitally. While taking a photo is quick, they often forget to do it (P9, 10) and find it cumbersome to transfer the photos to their laptop (P2), organize them (P2, 9, 21) and understand the messy content of the whiteboard after the fact (P22). As a result they prefer transcribing information onto a different substrate, such as their notebook.

Keeping Information "Just in case"

A quarter of the scientists (P1, 6, 9, 10, 14, 21) tend to hoard information (whiteboard photos, figures, versions of paper) "just in case" even though they rarely revisit it (P9, 10, 14), partially because they are not able to anticipate what will be needed in the future. For example, P21 (computer scientist) said: "It is really insane that amount of photos we have. We clearly do not use all of them."

Hoarding information adds to the challenge of future refinding. Participants find it difficult to determine the right version among their multiple devices: "Anyways, everything is mixed up (between home and work computers)." (P11). Participants use time stamps and modification events as primary cues to determine the right version. While prior research has focused on supporting document versions [START_REF] Karlson | Which Version is This? Improving the Desktop Experience within a Copy-Aware Computing Ecosystem[END_REF], we also found the need to support managing the versions and variants of graphs, particularly in scientists' data analyses. For example, P6 (bioinformatician) prints several versions of the same graphs as he iterates analyses and puts the latest version in a plastic folder to easily identify it.

Finding and Re-finding

All participants develop various strategies to support their future re-finding tasks.

Summarizing

Participants summarize information to avoid having to go back to the raw source. The summarized information is usually in another substrate that serves as a reference when re-finding. For example, P19 (experimental chemist) summarizes everything about a particular molecule in a physical album when she completes a series of experiments and has a clear result.

Linking related information

Five experimental scientists link related information together in their master lab notebook, like in [START_REF] Tabard | From Individual to Collaborative: The Evolution Prism, a Hybrid Laboratory Notebook[END_REF]. If they need to link digital content, they simply note down the file names. For example, P15 (computational chemist) writes down all the information related to a plot in his paper lab notebook, including location of the data, scripts to generate that plot, location of the Jupyter notebook of that plot and, name and location of the image file.

However, these manual links with file names break when participants change the name or location of the file, as illustrated by P16 (experimental physicist): "I have done a lot of cleaning of my files so I don't know if I can find it."

Saving data in a single place

Eight data scientists use a project-based organization to save related information in a single folder, similar to [START_REF] Tabard | From Individual to Collaborative: The Evolution Prism, a Hybrid Laboratory Notebook[END_REF]. But their tendency to hoard information and the messy results produced by exploratory programming [START_REF] Rule | Exploration and Explanation in Computational Notebooks[END_REF] result in folder clutter. For example, P18 (machine learning researcher) saves the data, the analysis scripts and the output in a single folder. As he produces variations and versions of the scripts and corresponding outputs, files accumulate, hindering re-finding.

Several participants use computational notebooks, e.g. Jupyter notebooks, to keep track of their analysis process by saving scripts and their outputs in a single place. However, as Rules et al. [START_REF] Rule | Exploration and Explanation in Computational Notebooks[END_REF], we found that these notebooks are routinely combined with other documents such as slides and ReadMe. This suggests that the strategy of saving data in a single place might not be flexible enough for scientists' knowledge management. They also need a lightweight way of linking related but distributed content together.

Preserving importance

The transition from one substrate to another is also a process where participants assess the importance of information. They usually preserve important information in a new substrate in a more structured way and discard information they do not need anymore. For example, P10 (mathematician) first works on paper, then selects the ideas he thinks are worth preserving and transfers them onto his paper notebook.

This process also applies to data analysis. P14 (bioinformatician) performs exploratory data analysis in one Jupyter notebook, where he produces many graphs and statistics. Once he is happy with the results, he copy-pastes them into his main Jupyter notebook, where he collects all the important results.

Iterating the Produce-Communicate-Reproduce Cycle

Communicating results often involves manually cleaning, selecting and inputting content into another type of document or software tool. Note that the results are often in the form of plots and graphs. Participants use a range of media for sharing their results including Microsoft PowerPoint (P22, [START_REF] Ghorashi | Leyline: Provenance-Based Search Using a Graphical Sketchpad[END_REF][START_REF] Beth Kery | Towards Effective Foraging by Data Scientists to Find Past Analysis Choices[END_REF] and Word (P22), Printout (P6, 13), LaTeX (P13), Google doc (P21), HTML (P15, 2), Markdown (P18) and Jupyter notebook (P14, [START_REF] Murta | noWorkflow: capturing and analyzing provenance of scripts[END_REF]. This supports the finding that data analysts transfer outputs of their analyses to an entirely different medium, e.g. slides or word processing document, for easier review [START_REF] Rule | Exploration and Explanation in Computational Notebooks[END_REF].

Participants' choice of medium is related to the audience they target. For example, P13 prefers to give his supervisor a paper printout because she is more likely to read it and get back to him. P2 (bioinformatician) prefers to share a static HTML file instead of an interactive Jupyter notebook because "what we have done in the project is that every group has its own expertise. If they want to change the parameters, they will ask you to change it. They won't do it directly." Some participants (P6, 22) complain that it is time-consuming to tediously copy-paste content into slides for easy sharing: "The problem is that you have to drag and drop into PowerPoint. So when you have 15 images, it is a bit time consuming." (P6) Scientists often face re-finding challenges when they need to modify content after getting feedback. For example, P18 had to recreate a graph after discussing with coauthors but could not find the data for that graph: "I did so many experiments that I could have accidentally overwritten the file..." After a modification, the new results need to be communicated again. Scientists need to manually re-execute the update pipeline by cleaning, selecting and putting content into another medium. P14 (bioinformatician) said: "There is obviously a problem of synchronisation. At some point, I generate the new version of a figure with slightly different parameters. I need to reload it in Overleaf. It happens often." Managing different file formats or variants adds more overhead, as P11 illustrated: "Including external files in LaTeX can get messy very very Issue Empirical Evidence (HF) Hard to re-find related but distributed information Related information is often distributed by necessity because scientists take advantage of the characteristics of different information artifacts (both physical and digital), resulting in difficult information re-finding.

(LT) Lack of tools to track inter-file relationships

Among various strategies to support future re-finding, linking is effective but limited because participants want to create different types of relationships among files and using file naming conventions is error-prone.

(MS) Manual synchronization

To share results, participants manually re-execute the pipelines that create the target documents.

(VM) Difficult version management

Participants' hoarding behavior and use of multiple devices adds to the challenges of re-finding and versioning. They have difficulty keeping track of versions of their documents, such as graphs.

(FV) Lack of support to manage file variants, e.g. format

Participants produce variants of a file for different purposes. Different variants of the same file clutter the folder, making it hard to manage.

(SD) Tedious creation of shared document

Participants complain that it is time-consuming and tedious to re-create shared document for review.

Table 1. Six issues observed in the formative study quickly. What? I want to use jpeg; I am pretty sure this thing is jpeg. But the browser is suggesting that it is not a jpeg."

In summary, the produce-communicate-reproduce cycle requires scientists to successfully re-find the original content, reproduce the results with new settings while keeping the previous versions and manually synchronizing the updated changes to another medium to communicate these results again.

Expressing Inter-File Relationships

We identified three types of inter-file relationships that scientists want to express: description, dependency and coexistence.

Description

To help re-find and re-understand in the future, participants often use text files to add explanations to other files, e.g. tables, images, pictures and code. Participants use ReadMe files (P14), tables of contents in notebooks (P15) and code comments (P6). For example, P21 (computer scientist) writes plain text files for each image in a folder to help re-find them.

Re-finding code is particularly challenging because it requires re-understanding the code. P14 (bioinformatician) finds computational notebook useful but still writes additional ReadMe files for each Jupyter notebook to explain the analysis to his future self [START_REF] Rule | Exploration and Explanation in Computational Notebooks[END_REF]. Other participants complain that out-of-order execution and unclear cell dependencies hinders the reproducibility of previous results. For example, P15 does not use a Jupyter notebook as a full-fledged lab notebook because he can accidentally re-run a code cell that overwrites the figure he wants to save. He still uses his paper notebook.

Dependency

Participants need to keep track of files that are generated by other files and manually keep them in sync. This often happens in produce-communicate-reproduce cycle when scientists need to manually modify and remix content across applications.

Coexistence

All eight data scientists put the data and analysis scripts (including Jupyter notebook) in sub-folders of the same folder to link the data with the corresponding analyses. P14 (bioinformatician) and his student created two separate but linked Jupyter notebooks because they use two languages (R and Python), that Jupyter does not support simultaneously.

Participants rely on file names to express inter-file relationships. However, links with file names are easy to break in case of renaming. File names are also used for other information such as experiment parameters, manual version suffix and file format, resulting in long, hard-to-understand file names.

Summary

This study shows that related information is often distributed by necessity because scientists take advantage of the characteristics of different information substrates. Their hoarding behavior complicates their versioning practices. They struggle to keep track, re-find and maintain consistency of this related but distributed information, particularly when collaborating asynchronously with students or colleagues.

FILEWEAVER

Based on the findings from the user study, we decided to focus on the file-related issues listed in Table 1. We designed FileWeaver, a prototype that augments traditional file management tools with automatic tracking and interactive visualization of file dependencies and histories. FileWeaver detects file dependencies and can update the dependents of a file when that file is changed. It also records file histories and can manage simultaneous versions and variants of a file.

FileWeaver User Interface

FileWeaver's interface has three interactive views (Fig. 1):

• A Folder View that displays all files in the current directory, similar to a typical file browser; • A Graph View that displays files as nodes and dependencies as directed edges. For example, a file containing a dataset loaded by a script is connected to the file holding the script; • A History View that displays the history of a file as an interactive tree, where each new version is connected to the previous one.

In all three views a menu with FileWeaver commands is accessible by right clicking a target or the background. The currently implemented commands are listed in Table 2.

Folder View

FileWeaver uses the standard Folder view of the host operating system (Fig. 1 left), with an added sub-menu in the context menu of each file to invoke FileWeaver commands.

The key command is Add File, which lets users add files to FileWeaver together with their dependencies. Files managed by FileWeaver have a little arrow on their icons to provide a visual cue.

File Dependencies and the Graph View

Each file added to FileWeaver is a node in a graph, and the dependencies between files are directed edges between the nodes. This graph is constructed and updated automatically. Whenever the user selects a file managed by FileWeaver in the Folder view, she can immediately see the dependency graph of that file in a separate Graph view. Most FileWeaver commands are available in both the Folder and Graph views.

Black edges represent regular, up-to-date dependencies. Other colors represent a different status: a green dashed edge indicates a FileWeaver copy (Fig. 1); a red edge indicates a stale dependency; a gray edge indicates a manual dependency, e.g. between a ReadMe file and a script; and a blue edge indicates the morph group of a file (Fig. 3). This makes navigating the file system flexible: the Folder view provides traditional navigation of the file hierarchy, the Graph view displays the dependencies of a file, irrespective of their location in the hierarchy, and the History view lets users explore the evolution of a given file over time.

Version Control and the History View

Use Cases

The combination of synchronized views, automatic dependency tracking and updating, and automatic versioning opens up new possibilities for managing files. We introduce the main features that we have implemented in FileWeaver through a scenario inspired by the thematic analysis, starring Jane, a data scientist. For each segment, we describe the scenario without FileWeaver and reference (in italics) the issues found in the thematic analysis. Then we describe the scenario with FileWeaver, showing how it addresses the issues.

Detecting and Maintaining Dependencies

FileWeaver automatically tracks the dependencies between files and displays them in the Graph view. When a new file is added to FileWeaver (either manually by the user or automatically by FileWeaver itself), FileWeaver detects its dependencies and adds them to the graph. When a user edits a file via the Edit and Update File command, e.g. by double-clicking it in the Graph view, FileWeaver updates all the dependent files and displays the result file. For example, if the user updates a LaTeX source file, FileWeaver opens the resulting PDF file. When she edits the script with Edit and Update File, FileWeaver updates all the dependent files by running the script and recompiling the LaTeX file, and opens the PDF file, with the up-to-date figure. When creating the Beamer file, Jane uses the Graph view to find the figure and opens its enclosing folder using the Locate File command. She can thus decide on the best file storage strategy. She then adds the Beamer file to FileWeaver (Fig. 2), so that any future change to the script will also recompile the slides.

Jane writes a ReadMe file and manually connects it to the script. The corresponding edge in the Graph View appears in gray. To send the project, she selects any file in the Folder or Graph View and issues the Make Archive command. This creates a .zip archive of all the files connected to that file.

Managing Variants with Polymorphic Files

Scenario without FileWeaver: Jane creates a very large plot and saves it as an SVG file. To facilitate importing and sharing this figure, she converts the file into PDF and JPG. She now has to maintain three files by hand whenever the source of the plot changes (Dependency).

Scenario with FileWeaver: Jane creates the three image files as above, and morphs them into a single file. Whenever she includes the morph in a new file, it uses the default image format for this file type. To use another format, she edits the edge attribute with the desired extension, which will from now on select the matching instance of the morph.

Managing History with Versions

Whenever a user edits a file via the Edit and Update File command, FileWeaver prompts for a descriptive message and saves the file as a new version. The user can explore the file versions in the History view, where each item displays the subject and date of the message, and compare any two versions using a GUI diff tool (Fig. 4).

Users who are not familiar with version control systems typically create their own versioning by making copies of files and editing them in parallel. FileWeaver provides the Copy File with Dependencies command, which lets the user work simultaneously on two versions of the files. These dependencies are shown in the Graph View as dashed green edges (Fig. 1).

Scenario without FileWeaver: Jane starts implementing a new feature. She makes several attempts and saves them under nondescript names (Keeping information "just in case"). A few weeks later, she returns to it but cannot figure out which file she was working on. She may even have overwritten it.

Scenario with FileWeaver: Jane creates a copy of her script with the Copy File with Dependencies command, so she can work on it independently from the original script. The copy shows up in the Graph view, linked to the original file with a green edge. As she works on the new feature, FileWeaver stores the successive versions. When she comes back to it a few weeks later, she uses the History View to display the differences between her last edits and remember her progress. When the feature is ready, she merges the copy into the original. If she gives up instead and deletes the copy, she can always get back to it later via the History view of the original file, which shows the branch corresponding to the copy.

How FileWeaver Works

We now describe how FileWeaver supports the features described above.

Graph Attributes

Nodes and edges of the graph have attributes that are stored in a separate database. Some attributes are maintained automatically, e.g. edge update time, which tracks when the dependency between two files was last brought up to date. FileWeaver compares it to the file's UNIX mtime attribute to decide whether to update the dependency. Each node also stores the version ID of the corresponding file, and each edge the version ID of the source side of the edge. If two files (A and B) depend on different versions of a third file (C), the edge (say, from C to A) representing the dependency that is not up to date is shown in red. This tells the user that A should be updated. If instead A and B were produced from C as part of the produce-communicate-reproduce cycle, it tells the user that the version of C that was used to produce A is accessible from the History View, whereas it would normally have been overwritten by the version that produced B.

Other attributes are under user control. For example, The user can set node update to false to specify that this node should not be automatically updated, e.g. because it is too computationally expensive to run the update. The user can also change the recipes for a given file (see next).

Recipes: Tracking and Updating Dependencies

FileWeaver uses file-dependent scripts called recipes, stored as node attributes, to track and maintain dependencies. These recipes specify how each file is processed (update), displayed to the user (interact) or its dependencies tracked (trace), allowing a high level of task automation and the ability to always keep the Graph view up to date

The update recipe processes the file and produces its output if there is one. For example, the recipe for a LaTeX file can simply be latexmk $filename. The update recipe is run whenever a file needs to be updated. When a user triggers a FileWeaver command on a given file, FileWeaver checks that the dependent files are up to date, in a topological sorting order, and launches the update recipe on the target file if an update is indeed needed.

The trace recipe is optional and should produce the same file accesses as update, only faster. If unspecified, the update recipe is used instead. For example, the trace recipe for a La-TeX file can be simply pdflatex $filename. FileWeaver traces the file accesses resulting from running the trace recipe when the file dependency list needs updating, e.g. when a file is edited or newly added. Trace recipes are motivated by files with long compilation procedures, such as LaTeX files: while the update call to latexmk will usually result in at least three calls to pdflatex, the trace recipe only needs a single one.

Update and trace recipes should include clean-up commands, if needed, to remove temporary files and avoid cluttering.

The interact recipe opens an editor or viewer for the file. For a LaTeX file, it calls the user's preferred LaTeX editor, e.g. texmaker -n $filename. FileWeaver runs the interact recipe when the user edits the file through FileWeaver, or when FileWeaver wishes to display a file to the user, e.g. to show the result of an update. When the user closes the editor (which exits the interact recipe), changes are automatically versioned. Note that the user can always edit a file outside of FileWeaver; it will then be recognized as out of date on the next call to a FileWeaver command.

We acknowledge that writing recipes may require some computing knowledge. We expect to provide more recipe to cover more file types, and a simple editor to facilitate creating, editing and sharing them.

Links and the Cookbook

The FileWeaver back-end runs in the background and strives to be as transparent as possible to the user. It uses a hidden folder called the cookbook to store its files.

Each file managed by FileWeaver is attributed a folder, called a cookbook page, in the cookbook. When FileWeaver starts tracking a file, that file is moved to a new cookbook page, and a symbolic (soft) link is created at the original file location, pointing to the file in its cookbook page. This leaves the user's folder virtually unchanged, except for the fact that the user now sees a symbolic link rather than a standard file. We use soft links rather than hard links because the latter do not span filesystems (including partitions). Also, most file browsers display symbolic links with an arrow on top of the file icon, giving the user a clue that the file is managed by FileWeaver.

A cookbook page also holds the version control repository for that particular file (Fig. 1 right). Cookbook pages are named after the device and i-node number of the file that they store, making for a cheap and memoryless, hashtable-like one-to-one mapping between files and cookbook pages 7 .

Tracking File History Through Version Control

Whenever a file is edited via the Edit and Update File command, FileWeaver prompts the user for a message and automatically commits the file to the version control repository located in the file's cookbook page. While FileWeaver could automatically detect file changes and perform actions, we avoided this behavior to give users a better sense of control. The FileWeaver Copy command creates a new cookbook page for the copy but shares the same repository as the original file so that the user can merge the two files with the Merge Files command. All edges to parent nodes and attributes are copied from the original file, preserving custom settings.

Polymorphic files

When the user select files and invokes the Morph Files command, FileWeaver adds these files to its cookbook as usual, and assigns them to a morph group. Instead of creating a soft link for each file, it creates a single soft link for the morph with a .gifc extension (generic image format container). When a file calls a .gifc extension, FileWeaver goes through the graph and looks if there is an edge between that file and a member of the morph group. If so it redirects the soft link with the .gifc extension to that morph group member; otherwise it goes through the default image formats associated with that file, e.g. pdf/png/jpg for a LaTeX file, and creates an edge with the corresponding morph group member. Whenever a file is used by FileWeaver, e.g. as part of an update, FileWeaver checks if that file uses a morph. If so, it makes sure that the soft link is pointing to the right member of the morph group. Since some systems, e.g. LaTeX, use the file extension of included files, FileWeaver creates a second, temporary soft link with the right extension, and runs a stream editor to search and replace the morph file name with the right extension. When the update is complete, the original file content is restored and the second soft link is removed.

Implementation

FileWeaver runs on Linux Ubuntu 18.04 LTS. The back-end is written in just under 5000 lines of Python with calls to standard UNIX tools such as bash and sed8 . File dependencies are detected by running Tracefile9 on the trace recipe to track file accesses. The graph database is managed via the graph-tool library 10 . The back-end currently runs only on Linux due to the use of Tracefile and strace, but we are considering alternatives for Mac OS.

The Folder view is the GNOME Nautilus file manager 11 (Fig. 1 left). We use nautilus-python 12 to write extensions to Nautilus for running the backend and adding the menu of FileWeaver commands to the standard Nautilus file menu.

Both the Graph and History views (Fig. 1 center) are implemented with NWJS 13 , a platform to create web-based desktop applications. The Graph View sends commands to the backend through a simple pipe, and receives updates to the graph through a shared file. It uses dot 14 for the layout of the graph. The version control system is Git 15 . Although not designed to deal with binary files such as figures, it can handle a moderate amount of them without problem. We plan to explore extensions to Git that deal with large or numerous binaries 16 . The History View directly calls Git commands for the different version management commands. It uses git2dot 17 to create the version tree and diff2html 18 to display version diffs. The FileWeaver Copy command uses the git-worktree feature to check out several branches at a time.

DISCUSSION AND EVALUATION

Table 2 lists the most important features implemented in FileWeaver and the issues identified in the formative study that they address (see Table 1). We complement this analysis with a more general qualitative evaluation of FileWeaver based on Green et al.'s cognitive dimensions [START_REF] Green | Cognitive Dimensions of In Proceedings of the Fifth Conference of the British Computer Society, Human-Computer Interaction Specialist Group on People and Computers V[END_REF]. We leave a formal, longitudinal user study to future work.

Visibility and Hidden Dependencies

Visibility is the ability to view components easily, while hidden dependencies reflects whether important links between entities are visible or not. FileWeaver achieves high visibility and low hidden dependencies by making dependencies among files explicit and visible in the Graph view. Dependencies are represented by edges that can be manipulated, e.g. change the update rule. Automatically running recipes also reveal dependencies as files are edited, unlike tools such as, e.g. Makefiles, that require manual editing to describe the dependencies.

In typical folder-based views, all non-hidden files are visible, which may clutter the folder. FileWeaver's polymorphic files let users view the multiple variants of a file as a single entity, making their relationship more explicit and reducing clutter.

Viscosity

Viscosity refers to resistance to change. FileWeaver has low viscosity because it automatically propagate the user's changes to a file to its dependents, achieving consistency between files without explicit user action.

FileWeaver also automatically stores successive versions of a file so that users can examine and revert to previous versions using the History view. It supports exploration of alternatives by making it easy to create parallel copies and merge them.

FileWeaver prompts the user for a message when a file is edited via Edit and Update File, which has high viscosity.

Although encouraging users to document their changes can help them re-find the right version in the future, this requires extra effort. We plan on simplifying this process, e.g. by suggesting auto-generated commit messages.

Error-proneness

FileWeaver reduces errors by automating the processes of dependency update and versioning. The former reduces the risk of running the wrong command to update files, and the latter makes it possible to get back to a former version in case of an error. In future work we plan to use version control also for the graph itself, which would make it possible to easily recover deleted files and dependencies.

Secondary Notation

Secondary notation refers to the ability to carry additional information. FileWeaver lets users tag files to rename the node labels while keeping the underlying files with their original name. Users can also edit the recipe and interact scripts of individual files to tailor them to their needs. In future work we will make it easier to define file types and edit default recipes, as they are not currently readily accessible to novice users.

Role Expressiveness

Role expressiveness refers to how obvious the role of each component is. Each view in FileWeaver has a specific role: Folder view for regular file management, Graph view for managing dependencies, and History view for versioning. Role expressiveness could be further improved by decoupling components and giving users more flexible ways to combine them.

Premature Commitment

Premature commitment refers to constraints on the order to complete tasks. FileWeaver limits premature commitment by letting users add files to the system whenever they want. File names, contents and locations can also be modified at any time.

Asking for a commit message when saving a file is a form of premature commitment, and should be made more flexible.

CONCLUSION AND FUTURE WORK

Knowledge management and sharing involves various specialized but isolated software tools, tied together by the files that these tools use and produce. We interviewed 23 scientists and showed that the information they manage is often distributed, because they take advantage of the characteristics of different information artifacts and rely on specialized tools. Although scientists develop strategies to cope with re-finding information, they still struggle to manage versions, maintain consistency and keep track of related distributed information.

We introduced FileWeaver, a prototype file management system where the traditional folder view is augmented by an interactive Graph View that displays dependencies among files and a History View that lets users interact with the different versions of a file, supporting navigation and re-finding tasks.

FileWeaver also features polymorphic files, which groups the different variants of a file into a single, generic format. Together, these features create a new information substrate that explicitly represents the web of file dependencies and relationships that users typically have to manage in their heads.

FileWeaver helps automate the workflows of knowledge workers who use files to manage information and tools such as scripts and compilers to process them. It weaves files into a graph of dependencies, providing users with an interactive visualization of these dependencies. It weaves the history of each file into a version tree, providing users with an interactive temporal view of the file. Finally it weaves existing tools that are part of the user's workflow together to increase automation.

We plan to evaluate FileWeaver in a realistic setting to gather feedback and improve the interface. We also need to assess its scalability on larger sets of files. Future improvements include making recipes editable by novice users, including through automatic capture of commands; simplifying the commit process, e.g. by suggesting commit messages; and detecting dependencies in files such as zip archives and Word documents. Finally, FileWeaver has great potential for collaboration, since the file contents and its relationships are under version control and can therefore be pushed to a remote server for sharing.

FileWeaver

  puts each file it manages under version control. When the user edits the file via the Edit File and Update command and saves it, FileWeaver asks her to enter a commit message and records a new version upon closing that file.The Show History command opens a History view where each node represents a version, labeled with the first line of the commit message and the time it was created. Branches corresponds to the use of the FileWeaver Copy command. Using the context menu, the user can open any version of a file and compare two versions with color-highlighted differences.Synchronization between ViewsThe Folder, Graph, and History views are synchronized and kept consistent. When the user selects a file in the Folder view, the Graph view updates to display the relevant graph. When FileWeaver detects that the dependencies of a file have changed, the graph is animated. The user can open a new Folder view at the location of any selected file in the Graph view, and a History view from either the Folder or Graph view.

Figure 2 .

 2 Figure 2. Graph view for the scenario (see text)

Figure 3 .

 3 Figure 3. Polymorphic file in expanded (left) and collapsed (right) form.

Figure 4 .

 4 Figure 4. History view showing the differences between two versions.

Table 2 .

 2 How different features of FileWeaver address issues observed in the formative study

	Command Name	FileWeaver Action	What users see	Issue Addressed
	Add File as Link	Start managing the file and add all dependent files	New nodes and edges appear in the Graph view. The files become links in the Folder view	MS, HF, LT
	Copy File with Dependencies	Copy a file with FileWeaver with all its user-defined FileWeaver attributes	A node is added to the Graph view, pointing from the original node by a green arrow.	LT, VM
	Make Standalone Archive (Runnable and Flat Mode)	Export all dependencies as a .zip archive with/without parent directories	FileWeaver creates the .zip archive in the cur-rent Folder view location	SD, LT
	Tag File / Group	Change the tag (label) attribute of a file (or group of files)	Labels in the Graph view set to the tag.	HF
		Run the file's interaction script; commit changes	An editor pops up; on closing it, a text window
	Edit File and Update	upon completion. Update dependents in topolog-	prompts for a commit message. The Graph view	MS, VM
		ical order; run interaction script on last file	is updated and the new output file is displayed
	Locate File	Change the Folder view to the directory contain-ing the file	The file is highlighted in the new Folder view	HF
	Connect File	Add an edge between two nodes in the Graph view	The edge appears in light grey, different from other edges in the Graph view.	LT
	Disconnect File	Remove a permanent edge between two nodes in the Graph view	The edge disappears from the Graph view	LT
	Show File History	Populate the History view with the Git history tree	Each node in the history represents a commit. node displays commit date and subject FileWeaver copies appear as branches. Each	VM
	Morph Files	see § Polymorphic Files	Morphed files are linked together with blue ar-rows in the Graph view	FV
	Compare File Versions	Call Git difftool	A GUI diff tool appears in the History view to compare files	VM

https://mathworks.com/products/matlab.html

https://www.ibm.com/analytics/spss-statistics-software

https://www.gitkraken.com/b

https://www.sourcetreeapp.com/

See a list of GUIs at https://git-scm.com/downloads/guis/.

https://webpack.js.org/

Some text editors use temporary files that are renamed into the original file after saving, therefore changing the i-node number of the file. FileWeaver creates an additional, hidden hard link to the file when it is added to the cookbook page to prevent the i-node from changing. This hard link can also serve as a backup access to the file.

https://www.gnu.org/software/

https://github.com/ole-tange/tangetools/blob/master/ tracefile/tracefile.pod, which is a wrapper around Linux's standard strace (https://linux.die.net/man/1/strace).

https://graph-tool.skewed.de/

https://github.com/GNOME/nautilus

https://github.com/GNOME/nautilus-python

https://nwjs.io/

https://www.graphviz.org

https://git-scm.com/

such as git-lfs, git bup, git-annex

https://github.com/jlinoff/git2dot

ACKNOWLEDGMENTS

We thank Injung Lee for her help analyzing data for the interview study. This work was partially supported by European Research Council (ERC) grant n°695464 ONE: Unified Principles of Interaction.

APPENDIX

A .rcp file stores the three scripts used by FileWeaver by delimiting them with single-line markers: =DEFAULT-UPDATE, =DEFAULT-TRACE, =DEFAULT-INTERACT. It also stores the preferred image formats between the =DEFAULT-FORMAT-IMG marker, in case a morph is used. The name of the file is that of the file suffix it is associated with, e.g. tex.rcp for LaTeX files. The .rcp file for LaTeX files is as follows: