FLUD Format and Parser | Download | Installation | Operation | Results

FLUD generates four kinds of output: a parse file, an HTML file, a set of userpath files for VisVIP, and error messages. The first three files are all written to the $WEBLOG_DATA/website/sessions directory, as per the standard directory structure for WebMetrics.
Parse File The parse file is a highly stylized rendition of the original logfile. Its intended purpose is to serve as input to other automated processes, such as analyzers and visualizers. Instead of processing the logfile directly, they can invoke the parser to perform low-level syntax checking. The resulting parse file can then be easily analyzed for higher-level purposes, such as statistical summaries and the like.

Each logfile record is essentially a sequence of fields. Each field has a name and a value (e.g. time_zone=7). In the logfile, the field name may be implicit. Each record of the parse file describes one field of the logfile. The parsed record format is:

   field-name "=>" value-type "/" value
Some additional derived fields for the time value are also written. Finally, the parsed file contains a separator (a line of dashes) between the fields of one logfile record and the next. An example should help make this clear. The following two input records:
   qhead    2000/01/18-13:33:55.11 Questionnaire_22
   qrec     Q_006 "about once a week"
generate the following chunk of parsed file:
   rectype => L / qhead 
   time => T / 2000/01/18-13:33:55.11 
   days => I / 51561 
   secs => N / 48835.11 
   questionnaireID => L / Questionnaire_22 
   rectype => L / qrec 
   questionID => L / Q_006 
   response => A / "about once a week" 
Note that the original time field generates a days field and a secs field. The former is the Modified Julian Date, and the latter is the number of seconds within the current day. This makes it easier to calculate time intervals. The value-type field indicates the syntax of the value itself following the slash. See the table of parse file value-types for details. For detailed semantics, see the FLUD specification.

The standard suffix is "parse". Full file name is SessionName/SessionName.parse.

Pretty-print File This file is essentially a pretty-print version of the logfile. Indentation and color are used to clarify the file structure. Thus, this file is primarily oriented towards human review. If syntax errors are found, an error message will be inserted in the HTML file.

The standard suffix is "html". Full file name is SessionName/SessionName.html.

Userpath files for VisVIP These files are designed as input to VisVIP, which presents a 3D visualization of users' navigation of a website. Each task within the session generates a separate file (see Example 1 in the Operation page); thus, each file represents the web pages visited by the subject during a single task, and the length of time spent on each page. Each record in the file has two fields: a unique nickname for the URL visited and the number of seconds spent there by the user.

The standard suffix is "up". The naming convention for these files is

The TaskType is taken from the taskhead record in the logfile, and the TaskCount is simply a sequential count of the executed tasks in the logfile (prefaced by "t") to ensure a unique name if the same task is attempted twice. I.e. TaskType identifies the type of task attempted and TaskCount keeps track of the number of task instances. For example, if a subject tries to complete a "buy_shirt" task, then goes on to a "inspect_shoes" task, and then goes back to re-execute the buy_shirt task, the generated files would be named something like:
  • session37/buy_shirt-t1.up
  • session37/inspect_shoes-t2.up
  • session37/buy_shirt-t3.up

When generating userpath files ("u+" parameter), the $WEBLOG_DATA/website/webstruct subdirectory must contain an "url2nn.dat" file, to provide a mapping from the full URL of a page to a nickname. See Example 2 in Operation for more details.

Error messages and warnings Finally, whenever syntax errors or other anomalous conditions are encountered, an error message or warning will be written to the standard error device (STDERR). Syntax errors are also written to the HTML file.

Overview | Installation | Operation | Results | FAQ
Version 1.1
Page last modified: 15 May 2002
National Institute of Standards and Technology (NIST)