Imported from previous forum
Collapsible panels are an area that could be enhanced within the spec in my opinion. It would be nice to expand the spec to allow expanding to the left and right in addition to downward.
This would allow for a more efficent use of space to provide advanced features that don’t need to be readily shown. The current downward collapsing is nice, but can create a very elongated ticket if you pile them on. I believe most platforms support this type of feature, so I can’t see why it couldn’t be added.
Thoughts?
Collapsible panels are an area that could be enhanced within the spec in my opinion. It would be nice to expand the spec to allow expanding to the left and right in addition to downward.
This would allow for a more efficent use of space to provide advanced features that don’t need to be readily shown. The current downward collapsing is nice, but can create a very elongated ticket if you pile them on. I believe most platforms support this type of feature, so I can’t see why it couldn’t be added.
Thoughts?
Ability to communicate “slightly” tighter UI layout is another area the WG have heard some requests.
Original concept was to leave the UI to the OMS and try to avoid BDs being too “strong handed” in UI, leaving the OMS to be the trader GUI experts. There was broad paranoia that FIXatdl might allow BDs to directly draw tickets on OMS systems without their control and the phrase “it will be a cold day in hell…” was clearly heard during that FIXatdl design phase. As a WG we wanted to serve the business needs of ALL parties: Sell Side, Buy Side and the Buy Side independent agent - the OMS.
The GUI standards area is also way outside the domain of FIX. So reinventing the wheel at FIX in general GUIs is not desired. The last thing we want is to create some odd FIX / FIXatdl unique cascading style sheet like technology where others have already solved those problems with good generic, cross industry, standard solutions.
My personal advice is for FIXatdl to “creep very slowly” into making GUI suggestions for the benefit the OMS layout. Suggestions should always be 100% over ride-able. Leave the HCI / GUI design to the OMS.
Competition in HCI and trader GUI is healthy for this industry! The last thing FIXatdl would want to do is roll into that with something bureaucratic, that once implemented was very slow and difficult to change and update. Let GUI design standards be done by other standard groups. Let the OMS community excel (or fail) with their trader HCI/GUI designs.
That being said, if there are “ridiculously simple” small enhancements (ie additions vs. changes) to the standing FIXatdl schema, that allows BDs to better communicate their concept of how the controls layout ought to go, we should strongly consider them.
Again, personal comment here, I’d like to see this done via a very narrow SUB-SET of some otherwise very good OUTSIDE FIX standards - perhaps CSS? That way we are not reinventing the wheel where others have already done an outstanding job (and are likely to keep evolving / maintaining that technology area.) Then, if we need to creep yet another tiny step forward, the path is already set. Likewise, OUTSIDE the FIXatdl standard, there is a standard way to create a tight layout, i.e. draw the ticket, 100%. How to do that would be up to the OMS, however there would be a clear, easy, standard way to do it.
Do I sound political here? Yes, it’s political!
One of the simplest things suggested to date is a basic grid layout specification.
Again, we need more people to speak up here. We do feel a bit of pain out there in the layout “tightness” area.
Wish the OMS community, as a group here, would collectively speak up and directly help the WG out here. Let us know what would work for them in particular…
Hi Rick, All:
Conceptually, FIXatdl makes a lot of sense, but considering the pushback with respect to dictating the actual presentation of the algorithm parameters (in an OMS/EMS application), does it make sense to just not worry about any of it in the first place?
It seems that the relationships and constraints for the different algorithm parameters are the most important aspect of FIXatdl, and if OMS/EMS developers are just going to create their own specific UI, then the UI specifications in a FIXatdl ticket are just going to be ignored for the most part anyway… it would seem that you’d get more mileage by concentrating purely on defining the specifics of the parameters in the ticket and just ignoring the UI altogether. For instance, if a collapsible panel just becomes a “group” then we don’t have to think about that collection of parameters being displayed in an expanding/collapsing widget (no such thing in a WinForms app, for instance) and could think about it any the way that makes sense for our own specific platform - e.g. tab or groupbox on Windows, or whatever makes sense in Swing or Flex or whatever.
I think if it were just limited to high-level hints, e.g. tab/input ordering and grouping of related parameters, the implementers on the UI side would have more than enough to go on in terms of generating a platform-specific UI for a FIXatdl ticket…
It’s easier for me to be FIXatdl compliant if I’m dealing with something called a “collection” or “group” than it is to be dealing with something called a “collapsing panel” since I have to write a custom widget in Windows Forms to display such a panel, but I already have widgets for tabs, groupboxes, and so on…
Anyway, just a few quick thoughts on the subject.
Conceptually, FIXatdl makes a lot of sense, but considering the pushback with respect to dictating the actual presentation of the algorithm parameters (in an OMS/EMS application), does it make sense to just not worry about any of it in the first place?
I would classify collapsible panels as an ‘advanced feature’, and making them collapse right-to-left vs. bottom-to-top as an even more advanced feature (eg there may also be fewer UI environments that even support the feature). I believe it is warned/noted in the spec that some of the more advanced features may be ‘supported’ in a more vanilla fashion. Certainly, it is understood that one may only leverage the parameter section and not fully support the visual section.
Frankly, we’d get much greater utility and benefit from having the ability to express a simple ‘grid’ (# rows, # columns) than horizontally collapsing panels.
I think the debate over the more advanced areas of a standardized UI representation should not cloud the real-world advantages that, at least American Century can attest to, FIXatdl’s full UI support provides.