Toggling visual characteristics in outline view of notes from the same prototype using rule tab in the prototype


(Mark) #1

Here is an example I use to distinguish my news-item notes within outline view (notes from a news prototype where all start with the same badges etc…) yet to be published ( determined by a user boolean KA $published.

if($published){$Badge=“ok”; $OutlineTextSize=50;$OutlineBackgroundColor=white} else{$Badge=“Paperclip”;$OutlineTextSize=;$OutlineBackgroundColor=;};

The general solution is;

if ($booleanKeyAttribute) {$KeyAttributeOfYourChoice=newValue; and so on separated by semicolons } else {KeyAttributeOfYourChoice=previousValue; and so on as per first list to get back to previous values separated by semicolons }

Stick this code into the rules tab of the prototype, toggle the boolean on the actual items using the prototype and see the visual changes in outline view - hope that is helpful to those wanting to make some distinction between notes of the same prototype based on a true/false characteristic


(Andreas Grimm) #2

This is a nice one, @Markoconnor. Works very well. Thank you!


(James Fallows) #3

This is a clear and useful suggestion. (Meta-point: the discussion of the past month has, to me, revealed or re-emphasized how many tutorials, guides, how-to steps, and other resources actually are available. To give one example of many, Mark Anderson’s step by step tutorials indexed here really are something.)

On your point about toggles, a way to make the toggling even easier and more apparent is to select the “Use Columns” option from the View menu in outline view, and insert one or more columns with checkboxes for the relevant values. For instance:

There are checkboxes to toggle both $Urgent and $Completed, which are Boolean attributes. Then, along the lines proposed in @Markoconnor’s note, I added an if(condition) {action} else {other action} rule to the prototype for these items, to set up a visual display matching the toggles. If something is checked $Urgent but is not $Completed, you get the red flag. When you mark it $Completed, the badge switches to a green check. Ones not meeting those conditions have no badge.

That is done with this quick rule:

if ($Urgent & !$Completed) {$Badge="flag red"} else { if ($Completed) {$Badge="check mark"} else {$Badge=;} } 

Obviously you could change the way the nested if/then/else tests work. For instance, the initial if/else test could be for all $Urgent items, then you could branch on whether completed or not. But this is a quick way to do the job.

The point is simply to illustrate the way checkboxes can be used to handle the toggles. Thanks for leading off with this example.


(James Fallows) #4

Here is an updated question for the coding experts here.

I have an evolved version of the if/then/else code mentioned above, which is derived from things I use in “real” files. That version is (line breaks for clarity):

if ($Urgent)
{ if (!$Completed) {$Badge=“flag red”}
else
{ $Badge=“check mark”} }
else
{if (!$Completed) {$Badge=;}
else {$Badge=“ok”;} } }

That gives four different states. as shown in this screen shot: Urgent and not done (red flag); urgent and done (big green check); not urgent, but also done (little green “OK” check); and other (no badge).

But that’s not my question. My question involves coding style and efficiency. There are two ways (that I’m aware of) to build this code into TB. One is to make it the Rule of the prototype these items are based on. The other is to create a code-holding note, let’s call it “DisplayRuleNote,” whose $Text will hold the rule you work up – and then have an on-add Action for the parent container of these items, saying $Rule=$Text(“DisplayRuleNote”).

Is there any difference, at all, between these two routes to the destination? One preferred? Less fragile etc? Or are they functionally just the same?


(Mark) #5

For style I think the code-holding note is better. Oodles of space in the note and the formatting style built into the code type notes is designed for spotting mistakes.

Making the note a prototype ( with its rule set from a different code note) and letting notes inherit the rule (along with other attributes as required) I expect might be quicker than using an OnAdd container process ( wouldn’t the latter mean that any changes to the code would mean that notes would have to go through the on add action again manually? Prototype avoids that.)

For performance efficiency I’ve a hunch the code note route is quicker from the testing I’ve done this morning (but only on a small file) but the definitive answer from that will no doubt come from the other Marks.

Thanks for the tip about using columns in outline btw - interestingly changing the boolean via this route results in my visual changes ( flags etc…) occurring much more quickly than setting the attribute in the top of the KA text pane on an actual note - I’ve never used that view before and thought it was only available in attribute browser view


(James Fallows) #6

Thanks for the style and efficiency tips; useful to hear. And on the point above, I do understand the advantages of having the rule be built into the prototype, versus applying it as an On-Add Action. (Since, as you point out, the on-add approach wouldn’t keep it automatically updated as you changed the code in the note.)

I hadn’t thought of adding something like $Rule=$Text(“CodeNote”) to the prototype, because I had wondered whether that might lead to a snake-devouring-its-own-tail / I’m-my-own-grandpa recursive loop. That is, I could imagine problems arising from creating a rule whose effect is to specify the contents of that same rule.

But it all seems to work fine, and the $Rule gets updated in all items with this prototype when I change the code-holding note. (And, as noted in an earlier draft that I changed, but it’s still true: the prototype itself retains the $Rule=$Text(“CodeNote”) specification, while items based on the prototype have rules reflecting the full code from the note. An elegant touch.) Thanks for the guidance.


(Mark) #7

I loved the link!

There is an option to not make the prototype run its rule by unchecking the enable checkbox bottom left of the rule box in action inspector - Notes still inherit as you say and their enable checkbox is unaffected - It’s like the xpos/ypos properties of a prototype not passing on to notes based on that prototype - I’ve only just started to use this approach and it is indeed elegant


(Paul Walters) #8

@Markoconnor

What macOS settings are you using that yields that dialog with crisp black borders for controls?


(James Fallows) #9

Yes, I discovered this by accident in the course of trying to figure out the “Rule” question, and it is a very nice touch.


(Mark) #10

MacOs Sierra 10.12.6 Preferences–> General–> Appearence–> Select 'Graphite and check the ’ use dark menu bar and dock


(Galen Menzel) #11

This produces the gray color scheme, but doesn’t give the black border controls that @PaulWalters was curious about. To get those you go to System Preferences → Accessibility → Display and check the “Increase Contrast” checkbox.