WO2004072864A1

WO2004072864A1 - Dynamically configurable file display system

Info

Publication number: WO2004072864A1
Application number: PCT/AU2004/000174
Authority: WO
Inventors: Bahram Boutorabi
Original assignee: Neurocom Pty Ltd
Priority date: 2003-02-13
Filing date: 2004-02-13
Publication date: 2004-08-26
Also published as: WO2004072863A1

Abstract

A method of displaying one or more file-containing nodes on a display device. The method includes a number of steps. The first step involves determining, for each file of interest, a value of at least one attribute of that file. The next step involves storing the determined values of the attributes externally from the files. The next step involves receiving an indication, from a user, of a selected attribute in accordance with which the files are to be grouped. The next step involves displaying one or more nodes on the display device, such that each node contains those files having mutually similar attribute values.

Description

TITLE: DYNAMICALLY CONFIGURABLE FILE DISPLAY SYSTEM

PRIORITY

This application claims priority from Australian provisional applications 2003900649 entitled "Dynamically Configurable File Display System", 2003901154 entitled "Attribute Value Inheritance in File Display System, and 2003901211 entitled "Application Development Using Virtual Foldering and Metadata Inheritance", all of which are incorporated herein in their entirety by way of reference.

FIELD OF THE INVENTION

The present invention relates to the creation of a graphical representation of a set of files on a microprocessor-based device, such as a networked or standalone computer system. More specifically, the invention relates to a dynamically configurable file display system.

The invention has been developed to interact with Microsoft Windows Explorer, and will largely be described in this document with reference to that specific application. However, it will be appreciated by those skilled in the art that the invention can be embodied in many other forms and devices.

BACKGROUND

Any discussion of the prior art throughout the specification should in no way be considered as an admission that such prior art is widely known or forms part of common general knowledge in the field.

Since their inception, computer systems and mobile devices have been dependant on low-level software, which handles the interface to peripheral hardware, task scheduling, storage allocation and a user-interface. This low-level software is referred to as the operating system and is stored on the system as files. By definition, files are a collection of related data or program records stored as a unit with a single name. The operating system also provides the default interface to the user when no other applications were running.

The operating system is organized into directories or folders and files. A directory is a node in a hierarchical file system that contains zero or more, other nodes, which are themselves generally files or other directories. Originally, access to files was command-based and the user would have to know the exact location of a file in the hierarchy to gain access to it. This system tended to be quite "hit and miss" and was cause for a lot of anxiety, especially to those unaccustomed to the file system.

With the increased popularity of computers and mobile devices and the advent of graphical user interfaces, users were able to access files in a much more friendly and efficient way. However, the first graphical user interfaces were primitive and proved very cumbersome. They provided little more functionality than the text-based file system interfaces and still required complex search commands. However, searching was perhaps the only efficient way to find the desired information.

With the ever-increasing popularity of computers and mobile devices, and the increasing numbers of files and directories needing to be accessed and managed, many applications (computer programs with a user interface) were written to provide the basic ability to access files within the file system. Today, the most popular applications are those that represent files and directories in either an icon view or in a tree-like hierarchy. A number of examples of these are Microsoft Windows Explorer, Windows Commander, Konquerer, GNU Midnight Commander and xfm. These applications are known as File Managers. To improve the user experience and more realistically represent the real world filing cabinets, directories are sometimes called folders and these two expressions can be used interchangeably.

Folders are created to allow users to manage their files whilst providing a storage area, thereby limiting the number of files viewable at any one time. It is especially important that users view as much relevant information as possible and part of the reason why the tree hierarchy is so popular. In a typical arrangement (such as the default view in Microsoft Windows Explorer), the tree hierarchy provides a view of the file system via two side-by-side frames. The first frame displays the folder hierarchy, allowing users to expand and hide the directory structure as they wish. The second frame provides users with a view of the current elements within the selected folder. These elements can also be displayed in a number of ways, which include elements such as large icons, small icons and names. Additionally, this view may display other file system associated information, such as permissions or other file attributes; timestamps for file creation, last revision, last access and revision numbers. Additionally, folders can typically be deleted, copied, pasted, renamed and shared. Access to folders can be restricted and permitted, and a shortcut (or pointer) to a folder can be created.

While the idea of customizing a graphical representation of files and folders in a hierarchy is not new, there is a major limitation in the way this is currently done. The current approach of "putting a file in a folder" in any operating system environment was developed based on the functionality of physical filing cabinets. This has a fundamental limitation of "a given file being in a given folder". This approach does not cater for today's information storage and retrieval requirements where any given file may need to appear in many related folders based on user requirements. The problem is that with many previous attempts, the files and folders are displayed to users in a pre-determined static hierarchy. This does not allow users to dynamically create their own customised hierarchy where a file may "belong to multiple folders". Currently files are logically stored in a directory or folder hierarchy, limiting the access to files according to this static structure. At best, a user can order the files and folders within a directory based on attributes stored with the respective files. However, this is still a limitation, since the file still needs to be located in the physical directory for such ordering to take place.

It would be desirable to provide an improved way of dynamically presenting files to a user of a computer system.

SUMMARY OF THE INVENTION

It is an object of the present invention to overcome or ameliorate at least one of the disadvantages of the prior art, or to provide a useful alternative.

According to a first aspect of the present invention there is provided a method of displaying one or more file-containing nodes on a display device, the method comprising the steps of: detern-ining, for each file of interest, a value of at least one attribute of that file; storing the determined values of the attributes externally from the files; receiving an indication, from a user, of a selected attribute in accordance with which the files are to be grouped; and displaying one or more nodes on the display device, such that each node contains those files having mutually similar attribute values.

Preferably, each of the nodes is displayed as a virtual directory or folder, including a label indicative of at least one of the attributes and the attribute value of the files of that grouping.

Preferably, the method further includes the step of displaying the nodes in alphabetic, numeric, or alphanumeric order in accordance with at least one of the attributes and attribute values associated with the respective nodes.

Preferably, the method further includes the step of displaying a tree-based hierarchy of the nodes, in which at least some of the nodes contain other nodes, wherein at least some of the nodes in the hierarchy contain files associated with an attribute defined in relation to a node higher in the hierarchy.

Preferably, each of the nodes at a common hierarchical level beneath a particular node contains files having attribute values corresponding to that associated with the particular node.

Preferably, files for which no attribute value has been determined are displayed without being grouped together under a node corresponding to the relevant attribute.

Preferably, the method further includes the step of accepting, from a user, an indication of an alternative attribute in relation to one of the nodes, and redisplaying the files hierarchically within that node in accordance with the values of the alternative attribute.

Preferably, the step of displaying the nodes includes: displaying at least some of the nodes in a first pane; receiving selection data in relation to a first of the nodes in the first pane; and displaying at least a second node in a second pane, the second node being .a sub-node of the first node within the hierarchy.

Preferably, the step of storing the determined values of the attributes externally from the files comprises storing the determitied values of the attributes in a database.

Preferably, the database is adapted to store a plurality of pairs of attributes and attribute values in relation to each file.

According to a second aspect of the present invention there is provided a computer system comprising a database and a display device adapted to display one or more file-containing nodes, the system being adapted to: determine, for each file of interest, a value of at least one attribute of that file; store the determined values of the attributes in the database; receive an indication, from a user, of a selected attribute in accordance with which the files are to be grouped; and display one or more nodes on the display device, such that each node contains those files having mutually similar attribute values.

BRIEF DESCRIPTION OF THE DRAWINGS

A preferred embodiment of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 is a screenshot showing selection of a file attribute by which to order files into nodes, in accordance with the invention;

Figure 2 is screenshot showing the result of the dynamic folder selection of Figure 1;

Figure 3 is a screenshot showing selection of another file attribute by which to order files into nodes, also in accordance with the invention; Figure 4 is a screenshot showing the result of the dynamic folder selection of

Figure 3;

Figure 5 is a screenshot showing selection of a further file attribute;

Figure 6 is screenshot showing the result of the dynamic folder selection of Figure 5; Figure 7 is a screenshot showing a selection step for displaying a file property list;

Figure 8 is a screenshot showing the file property window showing the metadata attributes associated with the selected file; and Figure 9 is an illustration of detailed dynamically generated display hierarchy, in accordance with the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The present drawings are simplified partial screen captures of a preferred embodiment of the invention being operated on an IBM compatible PC running the Windows operating system. Such hardware and software are well known to those skilled in the art, and so will not be explicitly described in more detail. As shown, the preferred form of the invention is applied to Windows Explorer, which is the default in-built file management system used in this and previous versions of the Windows operating system.

It will be appreciated that the words "folder" and "node" are used interchangeably within this document, since "folder" is the Microsoft Windows nomenclature for such data structures. It will be appreciated that other operating system and file management applications may refer to an equivalent structure as a "directory", or other terms. It will also be appreciated that although the prior art term "folder" is used, it is not intended to imply that the functionality of the system as a whole is the same as prior art file display and management applications.

The functionality of the invention is, in the preferred embodiment, achieved by way of a software application configured to interact with both Windows Explorer and the graphical user interface that is used to represent files and folders on a display of the computer device. The appHcation handles access to the files stored within the file system whilst allowing a multi-dimensional graphical representation of files to be displayed to the user, as described below. This allows the user to create a completely dynamic and customizable representation of files in a virtual hierarchy according to the selection of file metadata attributes and their associated values. Prior to undertaking the various actions shown in the drawings, it is necessary to generate a file attribute database. This will typically be undertaken during installation of the software application of the preferred embodiment, and involves the software scanning through some or all of the files of interest to a potential user of the system. The precise extent of the scanning can be limited to a default or customizable set of locations or can be limited by file type. For example, in a typical stand-alone computer set-up, there will be no access to remote network drives, so the domain within which files are scanned might be limited to all locally available non-volatile storage, such as hard-disk drives and magneto-optical drives. Alternatively, the scanning can be limited to particular file types, such as various document types,

MP3s, MPEGs, and so on. Again, this can be customizable, or can be left at a default setting.

During the scanning procedure, various information is extracted from the files being scanned. The type of information will vary from file type to file type, and to the actual information available from a given file. For example, Microsoft Word documents store such information as author, version data and document title, so all such information will usually be sought in relation to Word documents. However, not all Word documents will have, for example, an author recorded against them. In this case, the information is not extracted. Other document types will have other information. For example, an MP3 will usually incorporate artist name, song title, and various encoding parameters such as bit rate. This information is extracted. For yet other file types, file-relevant information can be extracted.

In some cases, file types will be encountered that the application is not familiar with. A number of alternative approaches can be taken in such cases. For example, the file can simply be ignored and the user notified (or not) of its existence.

Alternatively, the typical areas within the file for storage of relevant information can be scanned looking for what looks like relevant data. Another approach is to request a human user to fill in details relating to the file, either during installation or at a later date. If the latter, the appHcation can record the file and its location to make it easier to go back and fill in additional details at a later date. Even if the application is unable to obtain application-specific information from any given file, there will still be basic, operating system level information available for all files. Under most operating systems, all files have a creation date, a name and an operating system attribute. Such information can be extracted from a file even if the application undertaking the extraction is not familiar with the file type.

As it is extracted, the information is stored in a database against the file it is extracted from. Once the extraction process is finished, the database will be populated with a series of file names against which are stored other file data or metadata. In a preferred embodiment, the database stores file specific data such as file name, size, date of creation and the like. The database also stores pairs of metadata properties and values. For example:

FileName=Contract Property=Customer Value=Telstra This means that if a user is looking for a contract which has Telstra as the relevant customer then the system will display a folder which has been labeled "Telstra." The file contract will be displayed within the "Telstra" folder.

A more detailed description of the dynamically configurable file display system of the preferred embodiment of the present invention appears below.

Referring to Figure 1, there is shown a two-paned display 100 under Windows

Explorer. The left-hand pane 101 shows a folder list headed "Folders", under which is a node called "D: Document Space". This node represents a virtual file structure representing all those files that were scanned as described in previous paragraphs. The right-hand pane 102 shows all files available for viewing under the "Document Space" node. Files with the extension "msg" are e-mail files, "gif" and "jpg" extensions represent image types, whilst a "doc" extension indicates a Microsoft Word document type. In this view, the size and type information that will usually be available is not displayed, although this is of no concern in relation to operation of the invention. In Figure 1, a user has used a mouse (not shown) to open a selection menu 103, which shows a number of options. The user has selected the "View By" option, which caused a sub-menu 104 to open. The sub-menu displays the available file viewing options. The user has highlighted the "Publisher" option in the sub-menu 11 104, and is about to select it by pressing the left-hand mouse button. It will be appreciated that other keyboard-based shortcuts or voice-activated systems could be used to navigate through the menu structure and make the required selection.

The result of making the "Publisher" selection is shown in Figure 2. Three nodes, named "Creative Digital Technology", "GPayments" and "Neurocom" have been generated and displayed in the left-hand pane as sub-nodes of "Document

Space". The "Document Space" node is highlighted, so the right-hand pane displays the three sub-nodes nodes and other files available under that node, hi this case, files "Document4.doc" and "Project5.jpg" have not been placed under nodes, since there is no publication information stored against them in the database.

In the embodiment shown, the sub-nodes have been ordered alphabetically by default. However, as with normal Windows Explorer functionality, by clicking on column headings (such as "Size" and "Type") it is possible to have the nodes in the right-hand pane reordered accordingly.

Referring to Figure 3, an alternative selection by the user is shown. Rather than selecting "Publisher" as the attribute by which to view the files, the user is about to select "Type". The result of the selection is shown in Figure 4. Now, different sub- nodes named "Microsoft Outlook", "Microsoft Word" and "PaintShop Pro" have been generated based on the files types ascertained upon reviewing the information in the database. It is, of course, merely coincidental that there are three nodes. As with the previous example, there are files ("Project4.vsd" and "Project4.wav") that have not had "Type" data recorded against them in the database. They are therefore simply displayed directly under "Document Space". It will be appreciated that the system could easily be modified to place such folders into a default sub-node that holds all the files for which no value has been captured for the selected attribute. This, however, is a question of implementation and is not related to the core inventive concept. Referring to Figure 5, the user has right-clicked on the "Microsoft Word" node to open a selection menu, and is about to select "Publisher" with the left mouse button. It will be noted, in passing, that "Type" in this sub-menu has a small icon beside it that indicates the documents have already been displayed by type.

Selecting "Publisher" results in the structure shown in Figure 6, in which three new nodes, named "Creative Digital Technology", "GPayments" and "Neurocom", have been generated and displayed as sub-nodes of the "Microsoft Word node. The "Creative Digital Technology" node is selected, resulting in all files associated with that node being displayed in the right-hand pane. It will be noted that the files in the "Creative Digital Technology" node in this case have already been restricted by file type, so only files that are of a Microsoft Word type and published by Creative Digital Technology have been displayed in the right-hand pane.

Turning to Figure 7, a further feature of a preferred embodiment of the invention is shown. By right-clicking on any file, a selection menu opens to reveal a number of options. A similar action happens in the prior art, although making certain selections in accordance with the present preferred embodiment results in a new action being performed.

In this case, selecting "Properties" of file "Project8-3.doc" results in the window of Figure 8 being displayed, showing the properties of the file. In the prior art, making such a selection would result in file properties stored with the file itself to be displayed. In the present case, however, the attribute values displayed are those stored in the database in relation to the selected file. In the preferred embodiment, some or all of the attribute values can be amended directly via the window shown in Figure 8, simply by highlighting the attribute and typing in a new value. There may be some restrictions on the attribute to be changed. For example, system level information such as date created might not be amendable. However, the Hmitations can be selected to suit the security and functionaHty requirements of the particular user or application to which the invention is being put. It is possible, for example to only display amendable information, or alternatively to display the information but lock it from being edited by an unauthorized user. When the information is amended, the database is updated accordingly. Where the amended information is also stored with the file, it particularly preferred that the amendment be recorded at that level too. This is to ensure congruity between the attribute values in the database and those stored at file level.

It will be appreciated that information can be added in relation to files by way of the window of Figure 8. For example, file "Project8-3.doc" for which metadata is shown in Figure 8 does not appear to have "Identifier" information defined in relation to it. If the user is aware of (or can locate) this information in relation to the file, it can manually be entered by way of the window of Figure 8. The information in relation to this attribute is then available in future as a user is dynamically customizing the file display. To ensure congruity of information, it is desirable that any changes to file properties made other than via the display application make their way into the database. Such changes will usually be made by the application programs that generate and amend various file types. Amendments can be managed at one level by performing a scheduled update based on information relating to date of last change (which is typically system level data and therefore available for all files). For example, using Explorer's search tool, the application can determine whether any files have been amended or created since the time of the last such update. Files falling into this category are scanned for their information and the database updated (if necessary) accordingly. Naturally, such an update could be manually commenced at a time chosen by a user, or automatically when a new application is installed.

It is also possible for the application to monitor system-level file interactions to determine when relevant amendments are made to file attribute values, and database updates made as required.

Figure 9 shows a more detailed hierarchy of nodes and files, in which various other attributes have been selected in relation to some of the nodes of Figure 7 in order to further categorize and group files having similar attribute values.

In relation to all of the illustrated and otherwise disclosed examples, it is critical to understand that the nodes that have been generated do not represent locations, as is the case in the prior art Explorer application. Rather, the nodes (or folders) represent virtual data structures that group files in accordance with common selected attribute values. The various files can be located anywhere on the user's device or PC, or at any location accessible by that device or PC. For example, some of the Word documents in Figure 7 might be located on a network drive only accessible to the user's computer via a Local Area Network, or even the Internet. However, the way in which the files are displayed preferably makes no reference to the file location, since in many cases this is not of relevance to a user. Of course, if it is of relevance at some level in the hierarchy, the user is free to generate a new level based on a location attribute, which can be by operating system directory or physical location, for example. However, this is clearly different from prior art directory structures in which location (or virtual location) is the basis for hierarchy display.

It will also be appreciated that in some embodiments, it may be desirable to allow the user to customize the attribute database in some way. Typically, this would involve allowing a user to generate one or more custom attributes that can either automatically or manually have values associated with them in relation to files of interest. For example, a particular event data could be specified, and Boolean "Before date" attribute defined.

Preferably, the default and custom attributes are defined in accordance with the Resource Definition Framework (RDF) standard model. This will allow the file metadata attributes to be flexible enough to enable the creation of the user-defined virtual hierarchy, whilst also providing a set of standards for defining files within the application level.

It is believed that for many users the ability to dynamically display files hierarchically on the basis of one or more nested attributes will allow easier, more powerful navigation options.

Although the invention has been described with reference to a number of specific embodiments, it will be appreciated by those skilled in the art that the invention can be embodied in many other forms.

Claims

1. A method of displaying one or more file-containing nodes on a display device, the method comprising the steps of: deterrnining, for each file of interest, a value of at least one attribute of that file; storing the determined values of the attributes externally from the files; receiving an indication, from a user, of a selected attribute in accordance with which the files are to be grouped; and displaying one or more nodes on the display device, such that each node contains those files having mutually similar attribute values.

2. A method according to claim 1, wherein each of the nodes is displayed as a virtual directory or folder, including a label indicative of at least one of the attribute and the attribute value of the files of that grouping.

3. A method according to claim 1 , further including the step of displaying the nodes in alphabetic, numeric, or alpha-numeric order in accordance with at least one of the attributes and attribute values associated with the respective nodes.

4. A method according to claim 1 , further including the step of displaying a tree- based hierarchy of the nodes, in which at least some of the nodes contain other nodes, wherein at least some of the nodes in the hierarchy contain files associated with an attribute defined in relation to a node higher in the hierarchy.

5. A method according to claim 4, wherein each of the nodes at a common hierarchical level beneath a particular node contains files having attribute values corresponding to that associated with the particular node.

6. A method according to claim 1 , wherein files for which no attribute value has been determined are displayed without being grouped together under a node corresponding to the relevant attribute.

7. A method according to claim 1 , further including the step of accepting, from a user, an indication of an alternative attribute in relation to one of the nodes, and redisplaying the files hierarchically within that node in accordance with the values of the alternative attribute.

8. A method according to any claim 4, wherein the step of displaying the nodes includes: displaying at least some of the nodes in a first pane; receiving selection data in relation to a first of the nodes in the first pane; and displaying at least a second node in a second pane, the second node being a sub-node of the first node within the hierarchy.

9. The method according to claim 1 wherein the step of storing the determined values of the attributes externally from the files comprises storing the determined values of the attributes in a database.

10. The method according to claim 9 wherein the database is adapted to store a plurality of pairs of attributes and attribute values in relation to each file.

11. A computer system comprising a database and a display device adapted to display one or more file-containing nodes, the system being adapted to: determine, for each file of interest, a value of at least one attribute of that file; store the determined values of the attributes in the database; receive an indication, from a user, of a selected attribute in accordance with which the files are to be grouped; and display one or more nodes on the display device, such that each node contains those files having mutually similar attribute values.