Properties for media items (images and web pages) are set using edit and check boxes on the Media panel.
Lucid Builder Media Properties panel.
The properties are:
Path and Thumbnail path – Displays the name and file system path of the selected file (and of its thumbnail for image files). This is not editable, and is displayed to enable you to locate files in the file system
Caption – When an image is displayed at full size in the Lucid Player it is annotated with a caption. The caption is also used to refer to the image in a menu list of images, when several images are attached to one item.
Comments – When an image is displayed at full size in the Lucid Player it may be annotated with comments. Use this box to enter the comment text.
Needs Revision – Check this to bookmark (for yourself and other key builders) that a media item needs to be revised later. Media items marked as needing revision can also be excluded from the key deployment process.
Publish – Check this to specify that the currently selected media item should be published when the key is deployed. This option is checked by default.
To view files that are currently attached to any item, select the item in the Features or Entities panels. The files attached to the selected item will be listed.
To view the full image or full web page for any attached file, either double click on the image or web page icon or thumbnail, or right click on the media item name and choose Open. The file will be displayed at full size in a popup window.
Media files that have been attached to an item may be unattached from that item by selecting the file in the Media panel’s file list and clicking the Remove Media button, or right-clicking on the file in the appropriate directory and choosing Remove. The file will be removed from the currently selected item, but will not be deleted from the Media directory.
You may delete media files from the Media directory by right-clicking on the file in the appropriate directory and choosing Delete. The file will be removed from the currently selected item and from any other items to which it has been attached, then deleted from the Media directory.
Note
Deleting web page files from the HTML directory may cause broken links on other pages. Lucid does not check for this. Use a Link Checker application to ensure your keys HTML content doesn't have any broken links. For a great free open source link checker see https://wummel.github.io/linkchecker/
JPEG, GIF or PNG images may be attached to any Feature or Entity. If an image is selected outside the scope of the keys Media folder, a copy of the selected file will be made to the key’s Images folder. Images are copied to the Keys Image folder (or sub folder) so that all images are accessible when compiling the key, even if the original images have been moved or are on an inaccessible drive.
To attach an image to an item (Feature or Entity), first select the appropriate item. Right-click the Images folder in the Media panel or click the Attach Media button. To attach a local image file, choose the Attach Image File menu option and choose the file using the Open File dialog box that appears.
Lucid Builder attach image options
Note
When attaching local image files to your key, remember that a copy of the original file is created in the key’s Images directory. Editing the original file will have no effect on the key. You may edit the copy of the image in the Images directory using third-party image manipulation software.
When you attach an image to an item (Feature or Entity), the Lucid Builder will create a thumbnail image from the original, and store it in a Thumbs directory in the key’s folder with the same file name. Thumbnails are used for displaying the images in the Player’s Features and Images panels.
By default, thumbnail images are created with a maximum dimension (height or width) of 128 pixels, with the aspect ratio of the original image preserved by default. You may choose to set the thumbnail images to a size other than default maximum pixels by selecting from the menu Key…KeyOptions, then select the media icon. Within the Media options enter your preferred maximum thumbnail dimension in pixels. The Builder will then offer to automatically recreate any existing thumbnails. A warning will be given prior to this action occurring due to the amount of time potentially required to complete this operation in large keys with many image attachments. Alternatively, you can manually trigger the recreation of the keys thumbnails, via the main menu option ‘Key…Media…Update Thumbnails’.
In some cases, you may find it useful to create your own thumbnails instead of using the thumbnails generated automatically by Lucid. Remember to size the thumbnails to the dimensions specified in the Options dialog.
Web pages may be attached to any Feature, Couplet or Entity. The page may be remote to your local computer (that is, located on a Internet Web server accessible via a URL), or it may be a page that you have created and saved to the key’s HTML folder. If it is a local page in the key’s HTML folder, you should ensure that any media (images etc) associated with the page, and any linked pages, are also either saved to the key’s HTML folder or are remote World Wide Web resources.
To attach a web page to an item (Feature, Couplet or Entity), first select the appropriate item. Right-click the Html folder in the Media panel or click the Attach Media button. To attach a local file, choose the Attach Html File (Shortcut key Ctrl + L) menu option and choose the file using the Open File dialog box that appears. To attach a file by URL, choose the Attach Html URL (shortcut key Ctrl + Shift + L) menu option and enter the URL address (or paste a copied URL) into the dialog box.
Lucid Builder attach HTML media options
Important Note
When copying files to the HTML directory using your computer’s file management system, be aware that web pages often comprise many files (e.g. CSS, JavaScripts etc), all of which need to be copied correctly. Embedded images and hyperlinks to other pages will be broken if the files are not copied correctly, or if they have been assigned in the page using absolute rather than relative references. Consult your web page authoring software for more information.
Before beginning to attach multimedia files (web pages and images) to items in the key, you should understand the Lucid directory structure. In some cases, it is necessary to create files at the correct location within this directory structure before they can be attached to the key.
When a Lucid key is first saved, the Lucid Builder creates a set of directories for storing the various data files required. The basic directory structure for a key is as follows:
Lucid Builder default key folder structure
Save Directory is the folder you chose to save the key into. Inside this directory the Builder will write a file called {Key Name}.lk5 (where Key Name is the name given to the key in the Save As dialog box). Key Name.lk5 stores information necessary for the Lucid Builder.
The Key Name directory is created by the Lucid Builder at the time you save the key, and given the same name as the .lk5 file.
Data is a directory that stores essential key data.
Warning
Never alter any content within the Data directory, you will almost certainly irretrievably corrupt your key.
The media directories Media, Html, Images and Thumbs are created by the Builder to hold media files attached to the key. You may, if you wish, create sub directories within the Html and Images directories.
Web pages for attachment to items in the key must be authored outside Lucid, using HTML authoring tools such as Fact Sheet Fusion (available from Lucidcentral.org. For details see https://www.lucidcentral.org/fact-sheet-fusion/). Web pages (except external web pages accessible via the Internet) must be created in the key’s HTML directory (or sub folder), and must not refer to images and other media elements (e.g. CSS, JavaScripts etc) outside the key’s media folders. Otherwise, links will be broken when the key is moved to a different folder or deployed.
Images for attachment to items in the key may be sourced outside the key’s folders, or manually placed into the key’s Images directory (or sub folder) and attached from there. If a media file located outside the key’s Images directory and is attached to an item, Lucid will automatically create a copy of the media file in the key’s Images directory.
Note
Editing an original file located outside the scope of the key folder, for instance, at its original location, will have no effect on the copy held within the keys media folder.
The Thumbs directory holds thumbnails, created by the Lucid Builder, for all images attached to items in the key.
Features and Entities in Lucid keys can be provided with images and web pages, to help users and provide further information about the items. For example, Features and States may be illustrated with images and notes to help users understand the terms involved, and Entities may be provided with web pages including images, descriptions, notes on ecology, distribution etc.
Valid multimedia items are:
Images in JPEG, GIF or PNG formats, and URL references to images on the Internet.
Web (html) pages, URL references to web pages on the Internet and PDFs.
(Note that video and sound multimedia are accommodated in Lucid via the web page attachments.)
The Media tab to the left of the main window provides access to the Media Panel. This panel allows the user to attach all multimedia to items in the Features and Entities trees.
Properties for key items (Features, States and Entities) and subsets are set using the Items properties tab at the left of the main panels.
Item ID
The Item ID is a unique value assigned by the Lucid Builder to every element within the key. This value is useful when posting keys to a Web Server where the value can be used, for example, to preselect feature states via a custom web interface (e.g. a mapping system). Or for allowing third party applications such as Fact Sheet Fusion to map by ID rather than a text label.
List view name
In Lucid, features and entities are often arranged into hierarchical trees. The name of any item in the tree will often be conditional on its position in the tree.
Thus, the name of the feature Overall Shape in the tree at left only makes sense because of its position as a child of Pileus.
Lucid Builder List View Name example
At times, it is necessary to break up and rearrange the trees in the Lucid Player, as when the features are arranged in the Best order, or when entities are displayed ranked by their match value. At these times the features and entities are displayed as a list rather than a tree. For this reason, items should sometimes be provided with List View Names as well as Tree View Names.
By default, the Lucid Player creates a List View Name by recording an item’s path in its tree. Thus, the Overall Shape feature above would have a default List View Name of Pileus: Overall Shape.
The List View Name box on the Items properties panel is used to provide an alternative name to the default name. In the case above an appropriate name may be Pileus shape.
Lucid Builder Properties Panel – Items tab with Entity selected example
Note
List View Names for features only need to be provided for the lowest-level features - that is, those that have states as children or numeric feature nodes, since only these are displayed when the Player shows the feature in a list. Thus, the node Pileus above does not need a List View Name.
All nodes in the entities tree can be provided with List View Names, since all may be ranked in a list.
Item UID
The Item Universal Identifier (UID) is used for referencing the item in the Lucid Browser player and via JavaScript.
Comments
The Comments box is intended for annotating housekeeping comments to items. These comments are internal to the Builder and are not published with the key.
Needs revision
Check this box when the feature or entity is provisional and you intend to revise the data later (note that future releases of the Lucid Builder will include tools for finding and managing these items).
The Feature Type box displays and sets the type of Feature in the Features panel. There are four types of Features:
Multi-state Features have states as children;
Grouping Features have other Features as children;
Numeric Features, that have no children and;
Text Features used in Natural Language Description generation and is not output in the key for use within the Lucid Player.
The Feature type may be set at the time the Feature is added to the Features panel, or may be changed at any time via the Items property panel. A multi-state Feature may not be changed to a numeric or Grouping Feature until all its states have been removed. A Grouping Feature may not be changed to a multi-state or numeric Feature until its children have been removed. If a numeric Feature has been scored and is changed to a multi-state or Grouping Feature, its score data will be lost and cannot be retrieved.
List View Node
When the Lucid Player displays its features in a list rather than a tree, all multi-state and numeric features are listed but grouping nodes are not. On the entities side, however, there are no predefined rules for inclusion in the list. Therefore, when the entities panel is active, the List View Node checkbox appears and is used by the author of the key to specify whether an entity is to be included or excluded from the entities list. By default all entities added to the Entities tree are checked for inclusion in the entities list; un-check the checkbox if you wish the entity to be excluded from the list. Entities that are terminal in the entities tree (that is, entities without children) must be list view nodes; the checkbox for these nodes cannot be unchecked.
The List View Node checkbox is only available when an entity is selected.
Default Subsets
Lucid Builder Properties Panel – Entity Subset selected example
By default a multistate Feature is included in the Lucid Player’s Best algorithm. Instances where you have esoteric or difficult to answer Features you may wish to exclude them from being offered via the Best Function. In a large key with many Features excluding some Features can help speed up the Best algorithm on the Lucid Mobile Platform where some older devices may have under powered CPUs.
Tip
You can use the Key Reporter to reveal all Features excluded from Best.
Score Weight
The score weight setting modifies how the Feature is treated (weighted) in the Lucid Player’s Best algorithm. By default all Features are treated equally when calculating its rank within the list of Features available based on the Entities remaining. The ‘best’ feature (ranked first) is offered to the user for selection. By reducing the Features weight will cause the best algorithm to lower, not exclude, it’s ‘best’ ranking, while taking into account the weight settings of the other Features. For example, you may have a ‘powerful’ feature such as ‘Plant Family’ that is consistently offered as the ‘Best’ Feature to choose from, however your many of your keys users may not have this knowledge and will be forced to request the next best Feature. You can reduce the score weight of this so it may be ranked several orders down the ‘best’ rank and offered to the user as the best character when other easier Features have been exhausted.
In older versions of Lucid Builder you needed to decide at a global level for your key how the Lucid Player treated multi selections of States within the same Feature. That is using the logic of AND (Match all states) or OR (Match any states).
Lucid4 now allows you to set the matching logic on a per Feature basis. This flexibility is particularly useful in diagnostic keys.
By default multi-state Features are set to use the ‘Match any states’ setting (OR logic).
Single state selection
By default the Lucid Player allows the user to select one or more of the States of a multi-state Features. Selecting the Single state selection option will set the Feature to allow only a single State to selected on the Feature. After the user selects a State of the Feature further selections are disabled. As shown in the example screen shot below.
Lucid Player single State selection Feature example.
General properties for the key are set using the Key properties tab at the left of the main panels.
Lucid Builder Key Properties panel
Key Title
The Key Title should provide an appropriate, short, one-line name for the key, such as Key to Mangroves of Australia, Fly Families of the World or Common Diseases of Rice in South-east Asia. The key title is displayed as the header for the key window when the key is played in the Lucid Player.
Note that the title of the key is independent of the file name that is used to save the key. However, it will often be found useful to use the key title also for the file name, to help locate the key quickly on a hard drive or other storage.
Key Description
The Key Description provides a place to record any details about the key that may help you when you next open the key, or when you distribute your key to another party. Key Description may, for example, contain details such as the key’s purpose, target audience, limitations, version number and date etc. The information in Key Description is not published with a compiled key.
Key Authors
Key Authors provides a place to record authorship and authorship details (such as email addresses etc). The information in Key Authors is not published with a compiled key.
Tip
You can enter basic HTML tags within the title, description and author text areas. This information can be used as a part of the key deployment process, if you elect to have the Lucid Builder create a home page for the key.
If you would like an introduction to HTML basics take a look at w3schools.com.
Dependencies are logical relationships between Features such that a State of one Feature controls the presence (or absence) of another Feature in Features Available.
Consider, for example, the following Features:
Lucid Builder Features example
Wing colour and Wing shape only have meaning when wings are present – if wings are absent, they are logically inappropriate in the key.
Lucid provides two ways of accommodating logical dependencies of this kind. In the Lucid Builder, you may set a negative dependency such that, in the Player, if a user chooses the state Wings: absent, then the features Wing Colour and Wing Shape will be removed from Features Available. Alternatively, you may set a positive dependency such that Wing Colour and Wing Shape are initially hidden and only appear if a user chooses the state Wings: present.
Dependencies can help to keep the list of Features Available cleaner and less cluttered, and help make some Features, such as Best, work better.
Tip
If a Feature has been given both a Positive and Negative dependency, the negative dependency will be given preference.
How to set dependencies
To set dependencies, click the Dependencies score button on the right hand score toolbar. In dependency scoring mode, two buttons will appear to enable the setting of positive and negative dependencies.
Lucid Builder Dependency Score options
You may set the dependent Features for a given controlling State, or the controlling states for a given dependent Feature.
To set dependent Features for a controlling State, first specify the ‘Controlling State’ by selecting the state in the Features tree then using the right-click context menu: the selected State will be highlighted, indicating that dependencies are currently being set for this State. Round dependency score boxes will appear alongside Features that may be controlled by this State.
To score a dependency, select the dependency type (positive or negative) and click the appropriate dependency score boxes.
Lucid Builder Positive Dependency Scoring example
Setting positive dependencies for a State. With Wings: present selected, positive dependencies have been set for Wing colour and Wing Shape. If the user of the key chooses Wings: present, these Features will appear in Features Available.
Lucid Builder Negative Dependency Scoring example
Setting negative dependencies for a State. With Wings: absent selected, negative dependencies have been set for Wing colour and Wing Shape. If the user of the key chooses Wings: absent, these Features will disappear from Features Available.
Lucid Builder Positive Dependency Scoring exampleLucid Builder Feature selection Dependency scoring example one
Setting a positive dependency for a Feature. With Wing shape selected, a positive dependency has been set on the controlling state Wings: present. If the user of the key chooses Wings: present,Wing Shape will appear in Features Available.
Lucid Builder Feature selection Dependency scoring example two
Setting a negative dependency for a Feature. With Wing shape selected, a negative dependency has been set on the controlling State Wings: absent. If the user of the key chooses Wings: absent,Wing Shape will disappear from Features Available.
To set controlling states for a dependent Feature, first select the Feature you wish to control by selecting it in the Features tree and using the right-click context menu: the selected feature will be highlighted, indicating that dependencies are currently being set for this feature. Round dependency score boxes will appear alongside States that may control this feature.
When to use positive and negative dependencies
The choice as to whether to set positive or negative dependencies will depend on the circumstances of the key and the likely key users.
In a key with all negative dependencies, at start-up (or when the key is restarted) all features will be displayed. Features that are logically inappropriate will be progressively removed from the key as the user proceeds. In the example used in the previous topic, a user with a specimen with blue wings would be able to address the Wing colour Feature at the beginning of the key, even before they have addressed the Wing presence Feature. This may be advantageous for your key. The disadvantage is that, at times, there may be many features at start-up that are not relevant to the specimen being identified.
By contrast, in a key with all positive dependencies, many Features will be hidden at start-up. You will effectively be constraining the choices your user may make: to be able to address the Feature Wing Colour they will need to first address the Feature Wing presence. The key will progressively unfold, becoming more applicable as the identification proceeds. This may be advantageous for your key. The disadvantage is that some Features will not be immediately available for use.
Note
It is possible to mix positive and negative dependencies in one key. Be aware, though, that dependencies may clash, or even contradict other dependencies. In all cases of conflict between dependencies, a negative dependency has priority over a positive dependency.
Positive dependencies, feature scopes and unfolding keys
Both positive dependencies and feature scopes may be used to create unfolding keys in which some features are hidden at start-up and are progressively added to Features Available as they become useful for the identification.
For more information on feature scopes, see the topic Not Scoped. For more on positive dependencies see the topic How to set dependencies above.
The difference between an unfolding key built using positive dependencies and one built using feature scopes lies in how the appearance of the hidden features is controlled. A hidden feature controlled using a positive dependency will be added into Features Available when its controlling state has been chosen, no matter what set of entities remains in Entities Remaining. By contrast, a hidden feature controlled using feature scopes will be added into Features Available whenever all entities in Entities Remaining are scored for the feature, no matter what set of states have been chosen from Features Available.
For example, consider an unfolding key to arthropods created using positive dependencies. Some features concerning wings are controlled by a positive dependency on the state Wings: present. These wing features will unfold into the key as soon as Wings: present is chosen, no matter which entities remain in Entities Remaining.
Consider the same key created using feature scopes. Some features concerning wings are scored only for the winged entities (that is, all wingless entities have been given the score Not Scoped for these features, while the winged entities have been given normal scores such as Absent, Common, Rare etc). These features will unfold into the key as soon as only winged entities remain in Entities Remaining, no matter which states were chosen to get there.
The choice of whether to use positive dependencies or feature scopes to create an unfolding key depends on personal preference and the likely way in which key users will approach an identification.
Report Dependencies
Reports on positive and negative dependencies contained within the key. Within large, complex keys with multiple dependencies set it is sometimes easier to view a report on dependencies, rather than selecting them individually, via the dependency scoring interface, to see what they may affect.
This option can be accessed via the ‘Keys…Scores…View Dependencies’ menu.
Lucid Builder Dependencies Report example
The Dependency Reporter reports positive and negative dependencies in two ways –
By the controlling State and;
By Feature.
By Controlling States
A controlling State is a Feature State that contains a Positive or Negative Dependency that will cause other Features to be added (positive) or removed (negative) upon its selection.
Within the report all controlling states are listed with the Features each controlling state will add or remove if the user selects that state.
By Feature
Lists all Features that have a positive or negative dependency set against it, along with the Features/State controlling that Feature.
on the right hand score toolbar. In dependency scoring mode, two buttons will appear to enable the setting of positive and negative dependencies.
