-
Does a tag assigned to a section apply to all items in that section?
-
Is there a way to find / edit all uses of tag?
-
Is there a way to globally edit a tag? For example if the tag was FUBAR and I wanted to change it to Departure FUBAR.
A tag assigned to a Section or List applies to the entire Section or List. Meaning if you add a tag to a Section or List it will either hide or show that entire Section or List. There is currently no way to find / edit all uses of a tag. It is something we will add to the backlog.
Thank you.
Another suggestion for tags would be for them to have multiple choices, or at least two. There are a number of procedures that are either A or B. For example:
Towered or non-towered
VFR or IFR
Hangar or Tiedown
The tags/filters are a powerful tool to adapt Mira to different operations.
An interesting suggestion. I will need to think through it a bit. Seems like tagging would be done the same way where you would tag things IFR, VFR, etc. And then a configuration screen where you would tie the tags together. So for example if IFR and VFR are tied together, then the UI would present a selection of radio buttons with VFR and IFR as options so you could select one. This could work with one-to-many as well like Landing Airport Class A, Class B, Class C or Class D.
Yes. The “configuration” screen you illude to would enable tieing tags together, probably in ways that have not yet been anticipated. Alternatively, to simplify implementation, the configuration could be a special List (perhaps special in name only) at the top of the Checklist where tags could be grouped within Sections enabling a tag to be in multiple groups. With the same editing UI, you would add a “tag” item that could be added to a “tag group” (aka Section) using all the same editing constructs you have today. A tag could then appear in multiple groups or in the simplest case the tag group would contain only one tag.
Then when today’s Filter UI is presented when a Checklist is reset, the user would select which “tag groups” to enable. It could most be done with almost no UI changes, and only minor changes to internal logic as downstream the logic would be looking at the same tag state flags you are presumably using today.
I’ve been using tags/filters quite a bit as a result when I start my checklist I have to go through about 15 filter switches. Is there a way to set a filter as an action from a picker list? It would be nice to defer some of the filter settings until later in a flight/landing and a picker list would be a convenient to defer the selection until later.
This would not necessarily be 1:1. I might select choice “X” from the picker list and then set filters A1, B3 and C4. This would solve the issue I raised last year and basically push the programming off to me rather than you.
The filters are something that run one time when a procedure is launched to filter it down. To allow it to dynamically be changed once in the checklist not as trivial.
So I guess we’ve reached the end of the evolution of tags/filters. They are what they are. Too bad because flying is nothing if not about addressing to a dynamic environment.
I think I said it was not trivial. We have by far the most dynamic capabilities of any procedure system and continually look at areas for improvement. We have rolled out new capability which will give you complete control of doing advanced requirements as you are requesting, and yes, put the programming on you. You will notice in the MiraCheck Cloud app some new properties such as Visible, Group Names and Value Triggers. These can be used to do very advanced things at runtime and should meet your dynamic environment requirements. We are still working on putting the documentation together, so stay tuned!
Looking forward to it and standing by for the documentation.
Here is some info to get you started. This explanation makes the assumption that you are very familiar with the structure of content in MiraCheck. Lists are the tabs that appear at the bottom of the app e.g. Preflight, Inflight. Sections are containers in a List that can be presented horizontal or vertical. e.g. Before Takeoff, Takeoff, Run-Up. Items are different component types you interact with. e.g. Checkbox, Yes/No, Text Input.
You will notice there is a new property on Lists, Sections and Items called Visible. This allows you to set the default state. If you unchecked Visible the List, Section or Item will initially be hidden. Using the Value Trigger panel under the Advanced panel of an Item, you can write script to change the checklist at runtime. We are introducing a Runtime API with functions such as setVisible, setHidden, setItemLabel1, etc…
A real-world use case. As you say flying is a dynamic environment. You may start a flight where all looks good, but the weather quickly changes, so when you started your checklist, you may not know you will be flying IFR. Say you have some IFR Approach content in the checklist, but you may only want to show it by asking a question in your Descent list like Do you want to do an approach? If you answer Yes, then you want to show Approach content. If you answer No then you would want to hide any Approach content. To accomplish this, you would put an ID on the content for the Approach. Maybe you created an entire List (tab) of content called Approach and you want to Show/Hide this tab on the answer to the question. You would put an ID on the Approach List in the Advanced panel like this…
ID: approach
You would also set the Visible property on the List to not be checked so that it is initially hidden.
If you ran the checklist right now, there would not be a List (tab) called Approach because you said it was hidden.
In your Descent section, you would then add a Yes/No item Do you want to do an approach? On this Item, you would then want to add a Value Trigger. This is in the Advanced Panel. Basically, when the value is set, either by answering Yes or No, it will trigger the script you write in the Value Trigger editor.
The following script will Show/Hide the Approach List.
if (mc.getValue() === "yes") {
mc.setVisible("approach");
} else {
mc.setHidden("approach");
}
An alternative, more concise way to write would be…
mc.setVisible("approach",mc.getValue()==="yes");
If you run the checklist now, when you answer Yes to the question it should make the Approach List (tab) visible, and when you answer No, it should hide the Approach List (tab).
With scripting you can get a lot more advanced, but this initial example should get you started with doing dynamic things to the checklist.
Here is a link to the complete Runtime API with further examples.
https://checklist.miracheck.com/runtimeApi/RuntimeApi.html
I started writing code in 1968, so this will work for me. But I eventually moved into marketing and then finance where I learned a lot about what makes a successful product. Here’s a little free advice.
The late Larry Tesler put forth the concept of Conversation of Complexity with which you may already be familiar.
You’re exposing more and more of the complexity of Miracheck to the user. You’ll get an enthusiastic response from some, and it makes it easier for you to add capabilities, but it ultimately limits your market. Most people don’t know how to write code or don’t want to write code. They want the magic and they don’t want to know what goes on behind the curtain.
I can write code, so it’s not an issue for me, but it makes it hard to recommend the product to those who don’t want to write code.
This would not necessarily be 1:1. I might select choice “X” from the picker list and then set filters A1, B3 and C4. This would solve the issue I raised last year and basically push the programming off to me rather than you. - Boatguy
This capability puts the infrastructure in MiraCheck to allow very advanced future capabilities. We could wait to expose or, expose early and get feedback. It is hidden behind an Advanced section for a reason. Over time, enhancements may be made to reduce complexity if it is a feature a lot of users care about. Honestly, very few at this time are requesting the level of control you are asking for, and spending a large amount of engineering on a feature that may be used by few is not something we have the resources for.
The following is a tutorial that we will publish soon for users interested in this type of capability. A lot of pilots are pretty technical and tinkerers and like to get under the covers on things. For many it is what attracted them to aviation.
Value Trigger Tutorial
BTW, the learning module was created in our parent product AmbiFi (http://www.ambifi.com), which is an Enterprise platform originally based on MiraCheck where we are scaling the methodology of “Smart Procedures” (you may be familiar with the book the Checklist Manifesto) to multiple verticals such as healthcare, hospitality and manufacturing. MiraCheck itself is a tiny niche. I myself am a pilot and MiraCheck is my giveback to aviation. Some capabilities that we roll into MiraCheck are preliminary capabilities we are adding to our Enterprise product where there are tech savvy users.
That’s all good news and I appreciate the giveback to aviation.