First time poster. I finally got a new USB3 supporting Mac (the new Pro - worth the wait), I’ve had the Saleae 8 pro in it’s box since I bought it ~6 months ago (pulling it out for the first time I’m shocked how small it is!)
My first observation and concern (running Alpha 2.2.1) is that the GUI doesn’t seem to support MacOS HiDPI scaling settings and seems to be displaying everything really small (native display resolution is seems.) It is possible that the design, fonts and so forth are just really small. Grey on Black looks nice, but isn’t great for readability as noted by the first poster. It may behove you guys to expose more of the GUI configuration to the end users which will improve accessibility.
Welcome!
We actually develop it mainly on Mac, however, we’re happy to fix readability issues. Can you give me some examples of small or unreadable text?
Just upgraded to Alpha release. Very nice with zoomable voltage scales for each channel when doing analog readings.
However it would be great with slower capture speeds. I need to monitor some logic levels for 15 min and 100 sample per second would be sufficient - and reduce to need buffer size.
I don’t know that a screenshot would be particularly helpful as basically all the elements are too small to be easily seen/read compared to my other apps (that admittedly I may have customized to make more readable via their preferences.) Your GUI has no ability that I can see to zoom the interface or customize fonts, colors, etc. This is typically a sign of poor accessibility, which even though your product is niche, in my experience improving accessibility provides value to everyone.
I’d imagine your user base has a lot of greybeards like me whose eyes are what they once were, and who may not have their monitors and electronics bench right on top of each other. I have 32" of high definition display, but I need to be within a foot of it to have any hope of reading anything in your app (or I have to change the settings of the OS just for Logic, which is silly.) As I said, this is an issue that I find unique to your software. I understand the aesthetic color choices, gray on black, thin lines, tiny fonts, it looks spare and beautiful, great for marketing and such. But tools are best judged on how they work for the craftsman, and this GUI on first impression just feels like it is wasting vast amounts of real estate to ‘whitespace.’ I have 8 channels, maybe I am using 2 or 3 at a time typically, and nothing scales to fill the viewport. Why? I put it in fullscreen and the thing is wasting more than 3/4 of the window, with a bunch of tiny traces packed at the top of the interface… If I have one channel open, fill the damn window with it. Use some of that space to make the timeline legible. White on blue protocol decoding labels, with no padding and tiny fonts?! Are you serious? At least you provide a secondary resizable sidebar where the same data is legibly displayed… oh wait, no you don’t. It is fixed in size, the font is the same ridiculously small size. Again, why? It’s like you are trying to make this interface able fit on an Apple Watch.
I know I’m coming off very negative, and I’m sure a lot of blame can be thrown at QT and trying to maintain cross platform parity, but I honestly think this is a real problem, it is solvable, and I want you to literally ‘step back’ and see if you can acknowledge it.
I’m not asking you to change your pretty defaults, I’m asking to expose the appearance configuration or implement some basic scaling to better use the real estate the app is given and improve the readability for people over 40 and users trying to leverage a computer scope that may not be directly adjacent to their bench.
Hey there!
We’d love to learn more about how you use the analog channels and how we can make the experience better for you. Would you be interested in sharing it with us (here or privately)?
I don’t find a way to reduce aquisition. The “export” data between two time markers is perfect but i don’t managed to re-import data.
So i put marker “1” and “2” at a write to a device (address 0x90) then just after a read (at adress… 0x91 ) i2cwr.sal (12.3 KB)
Love the new alpha 2.2.1!
But I have a suggestion in terms of movement inside the Logic software.
I’m using currently all 16 channels and therefore I have to frequently scroll up and down. Currently you have to be on the channels bar with your mouse to not zoom in but to scroll trough the channels. This is very irritating especially if you are used to other programs where you scroll up and down with your mouse wheel.
Now my suggestion: In addition to scroll up and down via the channels bar add the command “Ctrl + mouse wheel” to scroll. It seems like that this command isn’t used yet.
This would make my life so much simpler and I think that also other people would love this enhancement.
I completely agree. We’re just talking about that internally…
The Ctrl is already used for vertical zoom in/out on analog channels but we’ll find something
The default is the first item, 8-bit, read/write included. This is really only useful for microcontrollers which don’t have I2C peripherals, where in firmware, you might end up writing the address with the read/write bit included in your source.
However, for microcontrollers with I2C peripherals, it doesn’t really make sense to ever display the address in anything other than the correct 7 bit form.
I’ve changed the default in the I2C analyzer source code, and the next time we rebuild the analyzer libraries for the application, the default will be updated in the app.
@Bakafish I’m from the Saleae design team. Thank you so much for your feedback! We will look into this readability issue and fix it as soon as we can. In general we always try to make the contrast WCAG compliant. I was curious to know your display settings a little bit so that we can test on the similar settings and improve from there. On mac what display resolution you are using?
I appreciate the quick response. My primary display is a 32" 4k using the middle scaled setting (as you show in your screen shot.) I understand that is at the larger end of the spectrum, and you have to support laptops and smaller screens, but this is why it makes sense to me to allow a lot more elasticity into the interface.
WCAG is a great starting point, but HTML has a very robust mechanism for scaling, especially text elements. My browser is set at 125% for example, which is a good balance between readability and space utilization. This has zero impact on any well designed page or web interface.
Ideally (IMHO) the right side-bar should be resizable, and the font size for the protocol decoding should increase to fill it as the user changes the area allocated. The individual channels should also be vertically resizable instead of hardcoding the limited 1-8x multiplier, again with the waveform scaling to the space the user allocates. Double clicking the left hand “channel name & grabber” area should toggle the trace between a minimized (current tiny) view and whatever the user has set it to previously by resizing it.
Roll over text could be much larger, as the only reason it is there is because a user is intentionally to getting data from the graph. It disappears as soon as you mouse off, so it is not taking up real estate or otherwise cluttering the screen. Using the same exact miniscule font for the hover text as used by the timeline for example, is just a wasted opportunity to make the information more accessible. Forcing everything into the tiny header space you allocated is just boxing yourself in.
Lastly, it looks like there really isn’t true HiDPI support implemented (https://doc.qt.io/qt-5/highdpi.html) The fonts and graphs seem fuzzy when using the native OS scaling, and that coupled with the default size choices and hard coded elements only compounds the issue.
Again, apologies for telling you how to do your job and crapping on your product. There is really a lot to like, the overall design is very slick and ideas are good, just really frustrating to be unable to actually read any of it.
I believe that we’ll add an option to zoom in/out soon. It’s built-in in Electron and should be pretty easy to implement.
Are you using Logic 2 or Logic 1? On Logic 2 the sidebar is resizable and collapsible. In addition, you can resize the channel’s height however you want on Logic 2.
It’s completely OK to provide us honest feedback, no reason to apologize. Our job is to improve the product and make sure that it’s easy as possible to use
LOL, somehow I downloaded the latest 1.x branch thinking I was using this beta
I swear I have never seen this, glad to see you retroactively incorporated many of my suggestions
Looks like the font rendering is cleaner, the resizable channel graphs work way better (would still like to be able to toggle between minimized and expanded.) The resizable sidebar and tool selection is a much better use of space, overall many clear UI improvements over 1.x
I stand by all my comments about font sizes though. Everything is still super small (although some of the hover text is bigger than default, so you guys are on the right track.) Glad to see you are so much closer to my expectations than I realized.
)
