Topics

too big bother


Aaron Mehl
 

Hi all,
I am just not sure how to author in Dita, large windows in the interface. The rule is for tasks to keep them short. This would mean breaking procedures into separate tasks. The problem I have is that I have some very busy windows in the interface I'm authoring and I would like to keep things in one place if at all possible. That said, I will give an example of a very busy window. I started adding call outs to the graphic, but stopped, since in my opinion it is just way to busy. 
The Dita task doesn't even come close to giving procedural steps for all the parts of the window. I want to K.I.S.S but I am not sure what to do. Maybe a table??
Any help/ideas would be most appreciated,
Aaron
 
So here is an example:
-----------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE task PUBLIC "-//OASIS//DTD DITA Task//EN" "task.dtd">
<task id="payment_information">
  <title>Payment Information</title>
  <shortdesc>
    <draft-comment author="aaron">This has to be totally redone and then the graphic with call outs
      needs adding (scheduleNew.png)</draft-comment>
  </shortdesc>
  <taskbody>
    <context>To schedule a salary deposit transaction:</context>
    <steps>
      <step>
        <cmd>Click on <uicontrol>Deposit</uicontrol> in the <uicontrol>Payment
            information</uicontrol> slider. </cmd>
      </step>
      <step>
        <cmd>Choose <term>Direct Deposit </term>as the payment method, from the drop down
          list. </cmd>
        <substeps id="substeps_yv4_nm3_d4b">
          <substep>
            <cmd>In the <uicontrol>Account</uicontrol> combo box, choose the account to deposit your
              salary in.</cmd>
          </substep>
          <substep>
            <cmd>From the <uicontrol>Pay to/from</uicontrol> drop down list choose
                <uicontrol>From</uicontrol>, if it isn't already selected.</cmd>
          </substep>
          <substep>
            <cmd>Type <term>Job</term> in the <uicontrol>payto/from name</uicontrol>field.</cmd>
            <info>If job is already listed, go to the <uicontrol>category</uicontrol> combo box,
              otherwise:</info>
          </substep>
          <substep>
            <cmd> A dialog box opens asking if you want to add this
              payee/receiver.</cmd>
          </substep>
          <substep>
            <cmd> Click <term>Yes</term>.</cmd>
            <stepresult>The new payee job is added to list of payees.</stepresult>
          </substep>
        </substeps>
      </step>
      <step>
        <cmd>Choose <term>Salary</term> in <uicontrol>Category</uicontrol> list.</cmd>
      </step>
      
      <step>
        <cmd>Enter the date you get paid in <uicontrol>Next due date</uicontrol> field, either: </cmd>
        <choices>
          <choice>Type the date.</choice>
          <choice>Use the up and down arrows to select the date.</choice>
          <choice>Click on the calendar icon and select the date.</choice>
        </choices>
      </step>
      <step>
        <cmd>Enter the amount you get paid in the <uicontrol>Amount</uicontrol> field, either:</cmd>
        <choices>
          <choice>Type in the amount</choice>
          <choice>Click on the calculator icon and enter the amount. </choice>
        </choices>
      </step>
    </steps>
  </taskbody>
</task>
----------------------------------------------------
Then here is the graphic as an attachment:
  


Melissa Kershes
 

Hi Aaron.

 

The overall goal in this window (I suppose) is to “Edit a scheduled transaction” There are a few ways you can simplify this.

  1. Only document one way of using a control. Most windows users already know that there are multiple ways to do things based on standard controls. Use the most common path to enter the data.
  2. If you want to group things do it by section. So first describe the schedule name box etc. then move onto the Payment Information box.
  3. If you want to do a call out for controls with no label, number the image and then do the call outs in a table below. This will clean the interface of the image and allow for easier translation if that happens. DO NOT use call outs for controls that have labels. The users can read the label.

 

All of this together should significantly shorten your topic.

 

Melissa

 

From: main@dita-users.groups.io <main@dita-users.groups.io> On Behalf Of Aaron Mehl via groups.io
Sent: Friday, March 12, 2021 10:30 AM
To: DITA Users Group Moderators <main@dita-users.groups.io>
Subject: [dita-users] too big bother

 

Hi all,

I am just not sure how to author in Dita, large windows in the interface. The rule is for tasks to keep them short. This would mean breaking procedures into separate tasks. The problem I have is that I have some very busy windows in the interface I'm authoring and I would like to keep things in one place if at all possible. That said, I will give an example of a very busy window. I started adding call outs to the graphic, but stopped, since in my opinion it is just way to busy. 

The Dita task doesn't even come close to giving procedural steps for all the parts of the window. I want to K.I.S.S but I am not sure what to do. Maybe a table??

Any help/ideas would be most appreciated,

Aaron

 

So here is an example:

-----------------------------------------------------------------------

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE task PUBLIC "-//OASIS//DTD DITA Task//EN" "task.dtd">

<task id="payment_information">

  <title>Payment Information</title>

  <shortdesc>

    <draft-comment author="aaron">This has to be totally redone and then the graphic with call outs

      needs adding (scheduleNew.png)</draft-comment>

  </shortdesc>

  <taskbody>

    <context>To schedule a salary deposit transaction:</context>

    <steps>

      <step>

        <cmd>Click on <uicontrol>Deposit</uicontrol> in the <uicontrol>Payment

            information</uicontrol> slider. </cmd>

      </step>

      <step>

        <cmd>Choose <term>Direct Deposit </term>as the payment method, from the drop down

          list. </cmd>

        <substeps id="substeps_yv4_nm3_d4b">

          <substep>

            <cmd>In the <uicontrol>Account</uicontrol> combo box, choose the account to deposit your

              salary in.</cmd>

          </substep>

          <substep>

            <cmd>From the <uicontrol>Pay to/from</uicontrol> drop down list choose

                <uicontrol>From</uicontrol>, if it isn't already selected.</cmd>

          </substep>

          <substep>

            <cmd>Type <term>Job</term> in the <uicontrol>payto/from name</uicontrol>field.</cmd>

            <info>If job is already listed, go to the <uicontrol>category</uicontrol> combo box,

              otherwise:</info>

          </substep>

          <substep>

            <cmd> A dialog box opens asking if you want to add this

              payee/receiver.</cmd>

          </substep>

          <substep>

            <cmd> Click <term>Yes</term>.</cmd>

            <stepresult>The new payee job is added to list of payees.</stepresult>

          </substep>

        </substeps>

      </step>

      <step>

        <cmd>Choose <term>Salary</term> in <uicontrol>Category</uicontrol> list.</cmd>

      </step>

      

      <step>

        <cmd>Enter the date you get paid in <uicontrol>Next due date</uicontrol> field, either: </cmd>

        <choices>

          <choice>Type the date.</choice>

          <choice>Use the up and down arrows to select the date.</choice>

          <choice>Click on the calendar icon and select the date.</choice>

        </choices>

      </step>

      <step>

        <cmd>Enter the amount you get paid in the <uicontrol>Amount</uicontrol> field, either:</cmd>

        <choices>

          <choice>Type in the amount</choice>

          <choice>Click on the calculator icon and enter the amount. </choice>

        </choices>

      </step>

    </steps>

  </taskbody>

</task>

----------------------------------------------------

Then here is the graphic as an attachment:

  


Aaron Mehl
 

Thanks,
The reason I didn't go for numbered call outs with a table is because throughout the rest of the document my graphics have call outs (arrows and text boxes) and doing this for one or two windows would be inconsistent. But you are right I may have no other choice. I just had a thought, what if I made every section of the window a different task. I could then put a graphic with call outs for only that task. Hmn...
Aaron

On Friday, March 12, 2021, 10:41:01 AM EST, Melissa Kershes <sarala557@...> wrote:


Hi Aaron.

 

The overall goal in this window (I suppose) is to “Edit a scheduled transaction” There are a few ways you can simplify this.

  1. Only document one way of using a control. Most windows users already know that there are multiple ways to do things based on standard controls. Use the most common path to enter the data.
  2. If you want to group things do it by section. So first describe the schedule name box etc. then move onto the Payment Information box.
  3. If you want to do a call out for controls with no label, number the image and then do the call outs in a table below. This will clean the interface of the image and allow for easier translation if that happens. DO NOT use call outs for controls that have labels. The users can read the label.

 

All of this together should significantly shorten your topic.

 

Melissa

 

From: main@dita-users.groups.io <main@dita-users.groups.io> On Behalf Of Aaron Mehl via groups.io
Sent: Friday, March 12, 2021 10:30 AM
To: DITA Users Group Moderators <main@dita-users.groups.io>
Subject: [dita-users] too big bother

 

Hi all,

I am just not sure how to author in Dita, large windows in the interface. The rule is for tasks to keep them short. This would mean breaking procedures into separate tasks. The problem I have is that I have some very busy windows in the interface I'm authoring and I would like to keep things in one place if at all possible. That said, I will give an example of a very busy window. I started adding call outs to the graphic, but stopped, since in my opinion it is just way to busy. 

The Dita task doesn't even come close to giving procedural steps for all the parts of the window. I want to K.I.S.S but I am not sure what to do. Maybe a table??

Any help/ideas would be most appreciated,

Aaron

 

So here is an example:

-----------------------------------------------------------------------

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE task PUBLIC "-//OASIS//DTD DITA Task//EN" "task.dtd">

<task id="payment_information">

  <title>Payment Information</title>

  <shortdesc>

    <draft-comment author="aaron">This has to be totally redone and then the graphic with call outs

      needs adding (scheduleNew.png)</draft-comment>

  </shortdesc>

  <taskbody>

    <context>To schedule a salary deposit transaction:</context>

    <steps>

      <step>

        <cmd>Click on <uicontrol>Deposit</uicontrol> in the <uicontrol>Payment

            information</uicontrol> slider. </cmd>

      </step>

      <step>

        <cmd>Choose <term>Direct Deposit </term>as the payment method, from the drop down

          list. </cmd>

        <substeps id="substeps_yv4_nm3_d4b">

          <substep>

            <cmd>In the <uicontrol>Account</uicontrol> combo box, choose the account to deposit your

              salary in.</cmd>

          </substep>

          <substep>

            <cmd>From the <uicontrol>Pay to/from</uicontrol> drop down list choose

                <uicontrol>From</uicontrol>, if it isn't already selected.</cmd>

          </substep>

          <substep>

            <cmd>Type <term>Job</term> in the <uicontrol>payto/from name</uicontrol>field.</cmd>

            <info>If job is already listed, go to the <uicontrol>category</uicontrol> combo box,

              otherwise:</info>

          </substep>

          <substep>

            <cmd> A dialog box opens asking if you want to add this

              payee/receiver.</cmd>

          </substep>

          <substep>

            <cmd> Click <term>Yes</term>.</cmd>

            <stepresult>The new payee job is added to list of payees.</stepresult>

          </substep>

        </substeps>

      </step>

      <step>

        <cmd>Choose <term>Salary</term> in <uicontrol>Category</uicontrol> list.</cmd>

      </step>

      

      <step>

        <cmd>Enter the date you get paid in <uicontrol>Next due date</uicontrol> field, either: </cmd>

        <choices>

          <choice>Type the date.</choice>

          <choice>Use the up and down arrows to select the date.</choice>

          <choice>Click on the calendar icon and select the date.</choice>

        </choices>

      </step>

      <step>

        <cmd>Enter the amount you get paid in the <uicontrol>Amount</uicontrol> field, either:</cmd>

        <choices>

          <choice>Type in the amount</choice>

          <choice>Click on the calculator icon and enter the amount. </choice>

        </choices>

      </step>

    </steps>

  </taskbody>

</task>

----------------------------------------------------

Then here is the graphic as an attachment:

  


Chris Brand
 

Hi Aaron

I have similar (but not that complex) windows to describe, plus the use cases that come along. When I have set up my documentation concept in the beginning, I also thought about numbered callouts and a reference table. But then I decided against it, as I have to redo the screenshots (tons...) every half year or so and messing with the callouts every time I didn't like.

After some thoughts I came up with this:

  • I "translated" the whole UI into keys. So, each button, tab, title, table, checkbox, etc. got a key with its text.
  • In my "User Guide", I placed the window screenshots in separate "Functional Description" chapters.
  • Below the screenshots I listed and described all the UI elements a user can interact with in tabular form.
  • In the "Use" chapter, I then described the different use cases as tasks and placed a link back to the "Functional Description" chapter.

Separating how something works from procedures is what you should aim for. In a functional description you can describe everything to the last detail, where as in a task, only focus on the important bits.

See the two attached screenshots. Hope it helps.

Greez,
Chris.

Am 12.03.21 um 18:34 schrieb Aaron Mehl via groups.io:

Thanks,
The reason I didn't go for numbered call outs with a table is because throughout the rest of the document my graphics have call outs (arrows and text boxes) and doing this for one or two windows would be inconsistent. But you are right I may have no other choice. I just had a thought, what if I made every section of the window a different task. I could then put a graphic with call outs for only that task. Hmn...
Aaron

On Friday, March 12, 2021, 10:41:01 AM EST, Melissa Kershes <sarala557@...> wrote:


Hi Aaron.

 

The overall goal in this window (I suppose) is to “Edit a scheduled transaction” There are a few ways you can simplify this.

  1. Only document one way of using a control. Most windows users already know that there are multiple ways to do things based on standard controls. Use the most common path to enter the data.
  2. If you want to group things do it by section. So first describe the schedule name box etc. then move onto the Payment Information box.
  3. If you want to do a call out for controls with no label, number the image and then do the call outs in a table below. This will clean the interface of the image and allow for easier translation if that happens. DO NOT use call outs for controls that have labels. The users can read the label.

 

All of this together should significantly shorten your topic.

 

Melissa

 

From: main@dita-users.groups.io <main@dita-users.groups.io> On Behalf Of Aaron Mehl via groups.io
Sent: Friday, March 12, 2021 10:30 AM
To: DITA Users Group Moderators <main@dita-users.groups.io>
Subject: [dita-users] too big bother

 

Hi all,

I am just not sure how to author in Dita, large windows in the interface. The rule is for tasks to keep them short. This would mean breaking procedures into separate tasks. The problem I have is that I have some very busy windows in the interface I'm authoring and I would like to keep things in one place if at all possible. That said, I will give an example of a very busy window. I started adding call outs to the graphic, but stopped, since in my opinion it is just way to busy. 

The Dita task doesn't even come close to giving procedural steps for all the parts of the window. I want to K.I.S.S but I am not sure what to do. Maybe a table??

Any help/ideas would be most appreciated,

Aaron

 

So here is an example:

-----------------------------------------------------------------------

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE task PUBLIC "-//OASIS//DTD DITA Task//EN" "task.dtd">

<task id="payment_information">

  <title>Payment Information</title>

  <shortdesc>

    <draft-comment author="aaron">This has to be totally redone and then the graphic with call outs

      needs adding (scheduleNew.png)</draft-comment>

  </shortdesc>

  <taskbody>

    <context>To schedule a salary deposit transaction:</context>

    <steps>

      <step>

        <cmd>Click on <uicontrol>Deposit</uicontrol> in the <uicontrol>Payment

            information</uicontrol> slider. </cmd>

      </step>

      <step>

        <cmd>Choose <term>Direct Deposit </term>as the payment method, from the drop down

          list. </cmd>

        <substeps id="substeps_yv4_nm3_d4b">

          <substep>

            <cmd>In the <uicontrol>Account</uicontrol> combo box, choose the account to deposit your

              salary in.</cmd>

          </substep>

          <substep>

            <cmd>From the <uicontrol>Pay to/from</uicontrol> drop down list choose

                <uicontrol>From</uicontrol>, if it isn't already selected.</cmd>

          </substep>

          <substep>

            <cmd>Type <term>Job</term> in the <uicontrol>payto/from name</uicontrol>field.</cmd>

            <info>If job is already listed, go to the <uicontrol>category</uicontrol> combo box,

              otherwise:</info>

          </substep>

          <substep>

            <cmd> A dialog box opens asking if you want to add this

              payee/receiver.</cmd>

          </substep>

          <substep>

            <cmd> Click <term>Yes</term>.</cmd>

            <stepresult>The new payee job is added to list of payees.</stepresult>

          </substep>

        </substeps>

      </step>

      <step>

        <cmd>Choose <term>Salary</term> in <uicontrol>Category</uicontrol> list.</cmd>

      </step>

      

      <step>

        <cmd>Enter the date you get paid in <uicontrol>Next due date</uicontrol> field, either: </cmd>

        <choices>

          <choice>Type the date.</choice>

          <choice>Use the up and down arrows to select the date.</choice>

          <choice>Click on the calendar icon and select the date.</choice>

        </choices>

      </step>

      <step>

        <cmd>Enter the amount you get paid in the <uicontrol>Amount</uicontrol> field, either:</cmd>

        <choices>

          <choice>Type in the amount</choice>

          <choice>Click on the calculator icon and enter the amount. </choice>

        </choices>

      </step>

    </steps>

  </taskbody>

</task>

----------------------------------------------------

Then here is the graphic as an attachment:

  


Jonathan Hanna
 

Hi Aaron,

You do not have to limit yourself by using a task topic. When I started using DITA, I tried using the Concept, Task, and Reference topics and found they just did not work well for my projects. Instead of using a task topic, you may want to consider using a generic topic. Using a generic topic gives you a lot more freedom. I did not even realize using a generic task topic was an option when I started using DITA!

Best regards,
Jonathan


Chris Papademetrious
 

Hi Chris, Aaron,

Same here - we found strict (content-restricting) concept/task/reference topics too limiting. Although from a writing perspective, most of our writers do try to write each topic in a concept-ish/task-ish/reference-ish way.

 - Chris


Aaron Mehl
 

Thanks so much this is a great boiler plate for so many windows I encounter in the KMyMoney interface. I will copy it modified to my particular case. Coo dos for the insight.

Thanks so much,
Aaron

On Saturday, March 13, 2021, 06:54:21 PM EST, Chris Papademetrious <chrispitude@...> wrote:


Hi Chris, Aaron,

Same here - we found strict (content-restricting) concept/task/reference topics too limiting. Although from a writing perspective, most of our writers do try to write each topic in a concept-ish/task-ish/reference-ish way.

 - Chris


Aaron Mehl
 

Hi again could you show me one keydef and keyref and how you use it in the code?

Thanks,
Aaron

On Saturday, March 13, 2021, 07:47:34 PM EST, Aaron Mehl via groups.io <mehlzaidy770@...> wrote:


Thanks so much this is a great boiler plate for so many windows I encounter in the KMyMoney interface. I will copy it modified to my particular case. Coo dos for the insight.

Thanks so much,
Aaron

On Saturday, March 13, 2021, 06:54:21 PM EST, Chris Papademetrious <chrispitude@...> wrote:


Hi Chris, Aaron,

Same here - we found strict (content-restricting) concept/task/reference topics too limiting. Although from a writing perspective, most of our writers do try to write each topic in a concept-ish/task-ish/reference-ish way.

 - Chris


Aaron Mehl
 

Well I did look at the generic topic but started to feel like I was moving back into docbook a bit. For most of the topics that I use strict concept and task are fine, but maybe here is where I should be looking at generic. But in any case I still want to keep my topics short and sweet.
Aaron

On Saturday, March 13, 2021, 07:49:35 PM EST, Aaron Mehl via groups.io <mehlzaidy770@...> wrote:


Hi again could you show me one keydef and keyref and how you use it in the code?

Thanks,
Aaron

On Saturday, March 13, 2021, 07:47:34 PM EST, Aaron Mehl via groups.io <mehlzaidy770@...> wrote:


Thanks so much this is a great boiler plate for so many windows I encounter in the KMyMoney interface. I will copy it modified to my particular case. Coo dos for the insight.

Thanks so much,
Aaron

On Saturday, March 13, 2021, 06:54:21 PM EST, Chris Papademetrious <chrispitude@...> wrote:


Hi Chris, Aaron,

Same here - we found strict (content-restricting) concept/task/reference topics too limiting. Although from a writing perspective, most of our writers do try to write each topic in a concept-ish/task-ish/reference-ish way.

 - Chris


Chris Brand
 

Hi Aaron

I keep key definitions in a separate map and use topic-group elements to structure it. I then can search for the key in the "DITA Reusable Components" view and insert it (often as <uicontrol>).
See screenshot below for an example.



Greez,
Chris.


Aaron Mehl
 


Thanks, I saw this same issue on a old webinar but didn't get it then. I will print out your screen capture and spend some time on this. 

These aspects of Dita deserve my attention, wow,
Thanks,
Aaron

On Wednesday, March 17, 2021, 06:14:20 AM EDT, Chris Brand via groups.io <chrizzbee74@...> wrote:


Hi Aaron

I keep key definitions in a separate map and use topic-group elements to structure it. I then can search for the key in the "DITA Reusable Components" view and insert it (often as <uicontrol>).
See screenshot below for an example.



Greez,
Chris.


Chris Brand
 

Sorry, you asked for code view. Here you go.

Map with all UI keys:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE map PUBLIC "-//XPLM//DTD DITA Map//EN" "map.dtd">
<map>
...
?????? <topicgroup>
?????????? <topicmeta>
?????????????? <navtitle>field</navtitle>
?????????? </topicmeta>
?????????? <keydef keys="new_f_name">
?????????????? <topicmeta>
?????????????????? <keywords>
?????????????????????? <keyword>Name</keyword>
?????????????????? </keywords>
?????????????? </topicmeta>
?????????? </keydef>
?????????? <keydef keys="new_f_targetDir">
?????????????? <topicmeta>
?????????????????? <keywords>
?????????????????????? <keyword>Target directory</keyword>
?????????????????? </keywords>
?????????????? </topicmeta>
?????????? </keydef>
?????? </topicgroup>
...
</map>

Concept topic:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE concept PUBLIC "-//XPLM//DTD DITA Concept//EN" "concept.dtd">
<concept id="concept_jjh_vrd_n1b" xml:lang="en">
?????? ...
?????? <section>
?????????? <title>Section: <ph keyref="new_s_settings"/></title>
?????????? <p>In this section, you can define the project name and the project directory.</p>
?????????? <p>
?????????????? <table frame="all" rowsep="1" colsep="1">
?????????????????? <tgroup cols="2">
?????????????????????? <colspec colname="c1" colnum="1" colwidth="2*"/>
?????????????????????? <colspec colname="c2" colnum="2" colwidth="5*"/>
?????????????????????? <thead>
?????????????????????????? <row>
?????????????????????????????? <entry>Label</entry>
?????????????????????????????? <entry>Description</entry>
?????????????????????????? </row>
?????????????????????? </thead>
?????????????????????? <tbody>
?????????????????????????? <row>
?????????????????????????????? <entry><uicontrol keyref="open_f_name"/> (F)</entry>
?????????????????????????????? <entry>Defines the project name.</entry>
?????????????????????????? </row>
?????????????????????????? <row>
?????????????????????????????? <entry><uicontrol keyref="new_f_targetDir"/> (F)</entry>
?????????????????????????????? <entry>Defines the directory where the design data will be created.</entry>
?????????????????????????? </row>
?????????????????????????? <row>
?????????????????????????????? <entry><b>Browse</b> (B)</entry>
?????????????????????????????? <entry>Opens Windows Explorer to select a directory.</entry>
?????????????????????????? </row>
?????????????????????? </tbody>
?????????????????? </tgroup>
?????????????? </table>
?????????? </p>
?????? </section>
?????? ...
</concept

Good luck!

Greez,
Chris.



Am 17.03.21 um 16:16 schrieb Aaron Mehl via groups.io:


Thanks, I saw this same issue on a old webinar but didn't get it then. I will print out your screen capture and spend some time on this.??

These aspects of Dita deserve my attention, wow,
Thanks,
Aaron
On Wednesday, March 17, 2021, 06:14:20 AM EDT, Chris Brand via groups.io <chrizzbee74@...> wrote:


Hi Aaron

I keep key definitions in a separate map and use topic-group elements to structure it. I then can search for the key in the "DITA Reusable Components" view and insert it (often as <uicontrol>).
See screenshot below for an example.



Greez,
Chris.


Aaron Mehl
 

Thanks, 
That's exactly what I needed. I should have guessed that keyref could go in uicontrol, etc. but I just learned something new. I guess I will indeed need a separate map for my keydef's....
In fact I will have to reorganize my maps altogether. There is so much to learn....
Thanks,
Aaron

On Wednesday, March 17, 2021, 03:41:09 PM EDT, Chris Brand via groups.io <chrizzbee74@...> wrote:


Sorry, you asked for code view. Here you go.

Map with all UI keys:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE map PUBLIC "-//XPLM//DTD DITA Map//EN" "map.dtd">
<map>
...
?????? <topicgroup>
?????????? <topicmeta>
?????????????? <navtitle>field</navtitle>
?????????? </topicmeta>
?????????? <keydef keys="new_f_name">
?????????????? <topicmeta>
?????????????????? <keywords>
?????????????????????? <keyword>Name</keyword>
?????????????????? </keywords>
?????????????? </topicmeta>
?????????? </keydef>
?????????? <keydef keys="new_f_targetDir">
?????????????? <topicmeta>
?????????????????? <keywords>
?????????????????????? <keyword>Target directory</keyword>
?????????????????? </keywords>
?????????????? </topicmeta>
?????????? </keydef>
?????? </topicgroup>
...
</map>

Concept topic:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE concept PUBLIC "-//XPLM//DTD DITA Concept//EN" "concept.dtd">
<concept id="concept_jjh_vrd_n1b" xml:lang="en">
?????? ...
?????? <section>
?????????? <title>Section: <ph keyref="new_s_settings"/></title>
?????????? <p>In this section, you can define the project name and the project directory.</p>
?????????? <p>
?????????????? <table frame="all" rowsep="1" colsep="1">
?????????????????? <tgroup cols="2">
?????????????????????? <colspec colname="c1" colnum="1" colwidth="2*"/>
?????????????????????? <colspec colname="c2" colnum="2" colwidth="5*"/>
?????????????????????? <thead>
?????????????????????????? <row>
?????????????????????????????? <entry>Label</entry>
?????????????????????????????? <entry>Description</entry>
?????????????????????????? </row>
?????????????????????? </thead>
?????????????????????? <tbody>
?????????????????????????? <row>
?????????????????????????????? <entry><uicontrol keyref="open_f_name"/> (F)</entry>
?????????????????????????????? <entry>Defines the project name.</entry>
?????????????????????????? </row>
?????????????????????????? <row>
?????????????????????????????? <entry><uicontrol keyref="new_f_targetDir"/> (F)</entry>
?????????????????????????????? <entry>Defines the directory where the design data will be created.</entry>
?????????????????????????? </row>
?????????????????????????? <row>
?????????????????????????????? <entry><b>Browse</b> (B)</entry>
?????????????????????????????? <entry>Opens Windows Explorer to select a directory.</entry>
?????????????????????????? </row>
?????????????????????? </tbody>
?????????????????? </tgroup>
?????????????? </table>
?????????? </p>
?????? </section>
?????? ...
</concept

Good luck!

Greez,
Chris.



Am 17.03.21 um 16:16 schrieb Aaron Mehl via groups.io:

Thanks, I saw this same issue on a old webinar but didn't get it then. I will print out your screen capture and spend some time on this.??

These aspects of Dita deserve my attention, wow,
Thanks,
Aaron
On Wednesday, March 17, 2021, 06:14:20 AM EDT, Chris Brand via groups.io <chrizzbee74@...> wrote:


Hi Aaron

I keep key definitions in a separate map and use topic-group elements to structure it. I then can search for the key in the "DITA Reusable Components" view and insert it (often as <uicontrol>).
See screenshot below for an example.



Greez,
Chris.