Automotive and Embedded Networks
NI-XNET Database Editor Preview
I don't like the small scroll bar. My OS is set to 100% scaling, and with that my system scroll bars are 15px wide. Your program doesn't look like my OS at all, and the usable scrollbar size is at times 5px wide. This is because if you move too far to the right you aren't grabbing the scroll bar but instead are moving the splitter. Why not take NI's own advice and "Not reinvent the wheel" and use the system style controls built into the OS? If I zoom (more on that later) to a usable size I get 2px of usable width on this scroll bar.
When I'm looking at a list of signals in the tree, and I type the letter "T" I expect it to go down to the first signal that starts with the letter T. This is how the CG LabVIEW tree controls work, and it is how the older database editor works. I know that there is a search/filter tool but this is how LabVIEW's trees, and Windows Explorer works. I'd expect all of the tree to work this way.
For signals that have enumerations why aren't the enum value pairs viewable?
Related to a post I made today, but how can I set the signal enumerations from this UI for signals?
I always liked the bit packing view and it is improved even more, thanks. That being said I would find it valuable if I can right click on a set of bits from the frame view and have a "Go To Signal" and have the tree go to that signal. I get that I can click on the bits, and get the signal name, and then go there so this isn't that big of a deal.
How is the bit packing view created? Is this some LabVIEW code somewhere that I can leverage in my own application? Previously I know it was an ActiveX control.
Do we need the [F], [S], [E], and [P] placed in front of the Frame, Signal, ECU, and PDU names? We already have unique icons for each type, and the parent item of this child names what it is. I know these are signals because I had to open the "Signals" tree node to see these. It just seems redundant.
Why do I need a light and dark theme? Why not use the system colors from the OS and then the colors change based on the settings of the OS?
Why do I need a zoom level? Again the OS handles this. If things are too small the OS can scale things to make them bigger. Still I tested it and it doesn't remember the zoom level if I close and re open it.
How do I export as a DBC? One of the major benefits of the XNet database editor was that I could import a DBC, edit somethings about it, and then reexport it. Now when I go to export I can only pick XML. Since a DBC is only one cluster I'd expect I could right click on the cluster and select Export as DBC like the old editor.
Search is so much more usable, thank you. It is also crazy fast even with comments selected. Which makes me wonder if it would be better to have it update as you type similar to how VIPM does it.
Thank you for handling window resizing better.
Overall this is an update that is long over due and it looks good. Assuming an update can allow for exporting to DBC I see no reason why I can't use this over the old one. All of my other comments and complains are minor or can be worked around.
Since it has been a couple years since this preview I thought I'd try again to see if any significant improvements have been made to get feature parity with the existing database editor. There are a few things that are better, but several things have been left unchanged that are usability issues. Sorry if this is going to sound mostly negative. It is easier to find things that still haven't been addressed, but I will try to highlight things that have improved. This is with version 22.5.0.
Pressing a key still doesn't go the next match in the tree. This is a native LabVIEW tree feature, and one that LabVIEW developers are going to be familiar with. I also noticed that if a category has too many items it makes pages. So even if I could press "C" and go to the first signal that starts with C, I suspect that will only work if the page I'm looking at has a C.
Why are things broken up into pages? Can a tree not display more then 50 items under a parent? When has NI ever don't this before or suggested this in a UI/UX? Trees in programming don't work this way, and it is not intuitive.
Enum on signals are still missing. This admittedly isn't in the current database editor but it should be.
The prefix letters were removed. Thanks.
Still no copy and paste on signals or frames. It would also be nice to Copy and Paste between databases.
Light and dark mode themes are still not tied to the operating system settings. I honestly don't think there needs to be a theme to this at all, but if it is going to be there why have the user have to set it in the OS, and then have to set it in the program?
In both the light and dark mode, text selection is very close to the same color as non selected text. This is worst on light mode, and in a few cases I would double and triple click text but not realize it was selected.
Similar to the last complaint the selected row in the tree in light mode has a color very close to non selected. There is a green vertical line on the left which does help know a row is selected but I don't know why this color was selected other then to make it harder to see. What is wrong with the LabVIEW default colors?
Zoom doesn't belong in this tool. Okay that is just my opinion, but why be inconsistent with the rest of NI's tools? Can I zoom in and out in MAX, or NIPM? I've never thought I needed to be able to, and it feels unnecessary here, and at times leads to things being hidden from the UI.
Bit layout still has no interactive-ness. I'd like to double click, or right click and go to the signal.
Why is there a "Signals" section under a frame? Can we have anything under a frame other than a signal? If not it should be removed. Or since it is so common, have it go away, unless there is another category.
CTRL+F should jump to find.
Search still isn't updated on each key type. Search is so fast it should work this way just like in VIPM.
Back and forward buttons would be nice to have. Especially when you go to the search, type what you want, click the go to icon, then realize it isn't what you want and need to go back.
I asked about how the bit packing view was created and never heard back. I'd be interested in using this in my own application.
Still using non standard scrollbars that are often too small.
DBC Exporting is there. And honestly I prefer this method where Save defaults to a DBC, with an option to export to FIBEX. Most users aren't going to know what FIBEX is and would probably be confused if they needed to Export to DBC, but a Save did the FIBEX method.
Arb ID still is decimal only, no hex view which is probably more common then decimal.
We have a default Signal value, what about a default frame value? It would be nice to know what the default value of the frame would be, taking the default signals under it into consideration.
Why is payload length a drop down for CAN FD, but numeric for CAN? I say be consistent with using drop downs for both.
Splitters are the same color as the panes and it is hard to know what can be resized. At times the splitter appears invisible because it matches the color of everything around it. You just have to move the mouse around, and then be disappointed when it does resize there.
When looking at a signal or frame under an ECU, I'd like to be able to right click it and have it take me to that signal or frame in the list.
Similar to the last one, in the search results I'd like to be able to right click a signal or frame and go to that entry. I realize there is a location button next to it, but this wasn't obvious at first.
After spending a few hours trying to get used to the new editor, my eyes are strained. I went back to the current editor and there is much more contrast, making everything so much easier to see. Maybe I'm getting old.
And lastly, but most importantly. Why isn't this written in LabVIEW? It is quite disappointing when NI gives a message of using standard UI and UX elements, use the standard OS controls, use standard OS colors, and use the things built into LabVIEW. NI is proud to give testimonials about how many companies reduced their development time by going to LabVIEW over some other solution. And then NI turns around and develops a replacement tool for an existing one using all non-standard UI stuff and develop it in a language that isn't LabVIEW. Is this tool ever going to be released on Mac OS, or Linux? If it were written in LabVIEW then cross platform support would likely be a trivial thing to add. Instead this likely means this tool will forever be Windows only.
