Field Guide · Help

How to use the Maximo UI field guide and playground

What each page is for, how to use the playground, what every check means, the words we use, where the facts come from, and what this cannot do.

What this is, in one paragraph

Every Maximo screen is one XML file, called a presentation. Application Designer edits it; the server renders it. These pages let you read the reference for that XML, open the real screens IBM ships, edit them in your browser, and see what would go wrong before you import anything into a real instance. Nothing here talks to a Maximo server, nothing you paste leaves your browser, and every fact is labelled with where it came from.

The pages

Field guide: The long read: how a screen gets from XML to the browser, what the parts of a presentation are, how fields bind to data, how signature options and conditional properties work, what changed under MAS, and how to move screen changes between environments.
Controls reference: One page per control (a tag in the XML, such as textbox or table). It lists every property the control accepts, what values it takes, whether Application Designer shows it, how often the stock screens use it, and a real example. Use it when you are editing XML and need to know what an attribute is called or what it accepts.
Playground: Pick a stock screen or paste your own export, edit the XML on the left, and watch a schematic of the screen redraw on the right. Every field is checked against the real data dictionary. Click a control for its facts; apply a trick with one click; download the result.
Tricks: Thirteen small changes to a screen that need no Java and no scripting: a related field, a hover window, a default value, a dialog, a two-column layout. Each one shows the XML, names the stock screen that already does it, and applies to the playground with one click.
Versions: What changed on screen between the pre-MAS layout and MAS 9.2 (labels, toggles, table buttons, tabs, CSS classes, system properties), with the source for each change, and the three skins the playground can draw.

Using the playground, step by step

1. Pick a screen: The App list starts with "Stock · MAS 9.2": the 204 presentations exactly as IBM ships them in MAS 9.2, including LIBRARY, LOOKUPS and MENUS. Below them are the Assetize starters, then "Your own export…" for a file from Application Designer (Export Application Definition, or drop the XML on the page).
2. Choose the dictionary: The Dictionary list decides which release the field names are checked against. It starts on MAS 9.2, the current release. Pick 9.1 if that is what you run.
3. Choose a skin: Pre-Carbon, MAS 9.0, or MAS 9.1 and later. The XML does not change; only how the schematic lays it out (labels left or above, checkboxes or toggles, table buttons below or above, boxed or underlined tabs).
4. Edit: The editor on the left is the XML. Type, paste, or use Format to re-indent. The screen and the checks update as you type. Reset returns to the stock or starter version.
5. Read the checks: Under the editor, the list shows errors (red), warnings (amber) and notes (grey), each with the line it points to. Click one to jump to it. The count in the toolbar says "clean" when there are no errors. Section "What the checks mean" below explains every message.
6. Click a control: Click anything on the schematic and the inspector shows the control's properties, which of them the reference knows, the bound attribute's facts from the data dictionary (title, type, length, required, domain) and a link to the control's reference page.
7. Preview with real data: For Work Order Tracking, "Preview with real data" fills the screen with work orders read from the 9.2 lab, so you can see how long values wrap and which fields are usually empty.
8. Apply a trick, read the diff: The Tricks drawer applies one change. The result shows the lines that changed, a change summary you can paste into a ticket, and "Compared to stock" when you started from a stock screen.
9. Share or download: "Share link" copies a URL that restores the exact state (screen, dictionary, skin, your edits) — the XML is compressed into the address, so very large edits fall back to download. "Download" saves the XML to import into Application Designer.

Reading the screen

The right-hand side is a schematic, not a picture of Maximo. It draws the structure the XML describes (tabs, sections, fields, tables, dialogs, buttons) under the layout rules of the skin you chose, so you can see where a field will land and what kind of widget it becomes. It is deliberately not IBM's pixels; the point is to compare two versions of a screen, or a screen under two skins, at a glance.

A field with no label in the XML shows the attribute's title from the data dictionary, which is what Maximo does. A YORN attribute becomes a checkbox or a toggle depending on the skin. A domain-backed attribute shows the domain's values. A table draws its columns; a dialog is listed in the Dialogs strip and opens when clicked.

What the checks mean

Each message carries a rule id. Errors are things Maximo would reject or that would fail at run time; warnings are things worth a look; notes are information the checker could not turn into a verdict.

xml (error): The file is not well-formed XML: a tag was never closed, a quote is missing, or something sits outside the root. Fix the syntax first; nothing else is checked reliably until it parses.
missing-id (error): A control has no id. Every control needs a unique id; Application Designer refuses to import without one.
duplicate-id (error): Two controls share an id. Ids must be unique within a presentation; the second one shows the line of the first.
structure (error or warning): A control sits where it cannot: a tablecol outside a table, a tab outside a tabgroup, a sectioncol outside a sectionrow, something outside the presentation root, and so on.
unknown-tag (warning): The tag is not a control Application Designer registers and no stock screen uses it. Usually a typo; sometimes a newer or custom control, which the schematic draws as a plain box.
unknown-property (note): The attribute is not on the control's Application Designer property sheet and no stock screen writes it. It may still be read by a bean class or an add-on; the note is there so you look.
property-value (warning): The value is not one the property accepts: an inputmode that is not one of the seven INPUTMODE domain values, or a true/false property given something else.
control-version / property-version (warning): The control or property is recorded as newer than, or deprecated by, the release you are targeting.
dataattribute-unknown (error, or note): The field is bound to an attribute the object does not have in the dictionary you chose. The message suggests the nearest real name. It is downgraded to a note when the control sits under a licensekey (an add-on the harvested instance may not have) or when the dictionary is marked partial.
dataattribute-object (note): The control is bound to an object that is not in the harvested dictionary at all, so its attributes cannot be checked.
dataattribute-relationship (note): The control reaches its object through a relationship (on a table, a dialog, a data source, or a dotted attribute) that is not in the harvested relationship graph, so it cannot be followed. Custom and add-on relationships land here.
dataattribute-bean (note): The control sits under a dialog, table or tree whose set comes from a Java bean class with no mboname or relationship in the XML. The XML cannot say which object that is, so the attribute is not checked.
lookup-unknown (note): The lookup id is not one of the 410 tables in the stock lookups.xml. Your instance may define more; check with Export System XML.
sigoption-unknown (warning): The signature option is not in the harvested SIGOPTION inventory for this application. Create it in Application Designer (Add/Modify Signature Options) or check the spelling.
sigoption-unbound (note): A control carries a sigoption that no menu or button in the presentation uses. Valid (conditional display only), but make sure the option exists for the app.

Words we use

Presentation: The XML file for one application screen; one row of the MAXPRESENTATION table. The root tag is <presentation>. System libraries (LIBRARY, LOOKUPS, MENUS, RECHOVERS) use <systemlib> instead.
Control: One tag in the XML: textbox, table, section, dialog and so on. The controls reference has a page per tag.
Property: An attribute on a tag: dataattribute, inputmode, label, lookup. Application Designer shows most of them on a property sheet; the stock screens write some that no sheet shows ("XML only").
Registry: What the product itself says the controls and properties are: one CTRL_* object per control in the data dictionary, its attributes being the properties, plus the Designer's own property dialogs and the domains behind each value list. The reference is generated from the MAS 9.2 registry: 54 objects, 587 properties.
Stock screen: A presentation exactly as IBM ships it, read from a running instance. "Stock · harvested from the lab" in the playground.
Data dictionary: MAXOBJECT and MAXATTRIBUTE: every object and every attribute with its title, type, length, required flag and domain, read from a running MAS 9.2 (and a running 9.1).
dataattribute: The property that binds a control to an attribute. It can be dotted: ASSET.DESCRIPTION reads DESCRIPTION through the ASSET relationship of the current object.
Relationship: A named join between two objects (MAXRELATIONSHIP). Tables, dialogs, data sources and dotted attributes use them. 7,166 were harvested from a running instance.
datasrc: A named data source in the XML. A section, table or field can say datasrc="serv_add" to bind to whatever object that source yields; MAINRECORD means the presentation's main object.
beanclass: The Java class behind a presentation, table or dialog. When a dialog has a bean but no mboname or relationship, only the Java knows which object it shows.
Lookup: A pick-list dialog a field can open, named by id from lookups.xml (asset, location, valuelist …).
Signature option (sigoption): A permission a security group can be granted. Buttons and menu items reference one; any control can carry one so that only granted groups see it.
mxevent: An event name a button or column raises (dialogok, addrow, selectrecord). Handled by the bean class.
licensekey: A control marked with an add-on licence (CALIBRATION, SERVICEADDRESS …) renders only where that add-on is installed.
Skin: A set of layout rules the playground draws with. Pre-Carbon, MAS 9.0, MAS 9.1 and later. Skins never change the XML.
Lab-verified: The green label: read from a running Maximo instance, with the object, screen or endpoint it came from (lab://maximo/9.2/…).
Practitioner: The amber label: reported by practitioners in cited posts, worth confirming on your instance. Used for how MAS releases render, which no instance can be asked about.
XML only: A property the stock screens write that the control's Designer property sheet does not show.
Partial: A dictionary whose harvest was capped. Neither 9.2 nor 9.1 is partial today; the label would return if a future harvest were.
Cross-version check: A stock screen checked against a dictionary other than the one it was read from. The toolbar says so. It answers "would this binding still resolve on the other release", nothing more.

Where the facts come from

Everything labelled lab-verified comes from MAS 9.2. The data dictionary (2,326 objects, 43,403 attributes) and the sample work orders were read from a running MAS 9.2 through its own APIs. The rest was read from the demo database IBM ships inside its Manage image (manageadmin:9.3.31, whose MAXUPG is V9200-175): the 54 CTRL_* control objects and their defaults; the Application Designer presentation; 204 stock presentations plus the LIBRARY, LOOKUPS, MENUS and RECHOVERS libraries (usage, examples, lookup ids, menus, hover windows); the SIGOPTION inventory (7,502 options over 536 apps); MAXRELATIONSHIP (7,166 relationships); KPIMAIN, CONDITION and the conditional-UI tables; 592 domains with their values. The 9.1 dictionary (1,974 objects, 30,944 attributes) is there for anyone still on 9.1.

What no instance can be asked about — how each MAS release draws a screen — is taken from cited practitioner reports and IBM Docs, labelled as such.

What it cannot do

It is not Maximo: The schematic draws structure under a skin's rules; it does not run IBM's rendering, CSS or JavaScript. Widths, wrapping and exact placement on your instance will differ.
No Java runs: Bean classes, events, conditional properties (CTRLCONDPROP), display rules, signature-option grants and data restrictions are read as XML, not executed. A dialog whose bean picks the object cannot be checked; a field hidden by a condition still draws.
Stock screens are core Manage: The 204 stock screens are the ones core MAS 9.2 Manage ships. Industry solutions and add-ons (Oil and Gas, Service Provider, Spatial and the like) bring their own screens, which are not in this set.
Your instance is not the lab: Add-ons (Calibration, HSE, Spatial, Scheduler …), custom objects, relationships, lookups and signature options that exist on your instance and not on the lab show up as notes or unknowns. The checker reports what the lab knows; it does not know your customisations.
Property meaning is partly Assetize's wording: What a property is called, what values it takes, where the Designer shows it and how the stock screens use it are read from the product. The one-line summaries of what a control or property does are written by Assetize from that evidence; IBM publishes no current description to cite.
Framework tags have no property sheet: Tags such as tabledetails, menuitem, recordhover and the Spatial or BIM controls exist only as the stock screens use them. Their listed properties are the attributes seen, not a declared set.
Includes and menus are not expanded: An include draws as a reference to the library control, not the control itself; menus, lookups and hover windows are named, not opened.
Real data is 9.2 work orders only: The data preview exists for Work Order Tracking. Other screens draw empty fields.
Nothing is imported for you: Download the XML and import it with Application Designer yourself; test in a non-production environment first.
Rendering facts for MAS releases are second-hand: How 9.0, 9.1 and 9.2 lay out a screen is practitioner-reported. The skins are approximations of those reports, labelled as such.

Frequently asked

Can I trust the property list for my release?: Yes. It is what MAS 9.2 declares: 54 CTRL_* objects and 587 properties, with their 9.2 types. 9.1 has the same property names; 39 of them stored their value as ALN there and are LOWER on 9.2. The test suite checks both.
Why does a stock screen show errors?: Because the harvested instance is a core install. Stock WOTRACK against the 9.1 dictionary shows one genuine miss (WORKORDER.CALCEXPRESSION, a dynamic job plan field not on that instance) plus notes for bean-supplied dialogs and licensed add-ons. That is the checker being honest, not the screen being broken.
Does anything leave my browser?: No. Parsing, drawing and checking run in the page. The dictionaries are static files the page downloads; your XML is never uploaded. A share link carries your XML compressed inside the URL, so only send it to people you would send the file to.
Where is the type-ahead trick?: Removed. No stock screen carries a type-ahead attribute; Application Designer stores autofill as a configured datastore, not in the XML. The hover-window trick replaced it.
Can I add my own instance's dictionary?: Not from the page. The harvest tooling in the repository (lib/lab-harvest, lib/screen-sim) reads an instance through its REST API with an API key or a browser session; that is how the lab data was produced.
What do the 7.x version numbers on stock screens mean?: The version attribute on a presentation root is the format stamp the file was first written with. 164 of the 204 stock screens say 7.1.0.0 and 10 say 6.0.0; IBM never re-stamped them because the format never changed.