Honestly I think I’ve felt the same as every one of these comments since v18 was released.
I am anxious to test v18 for accessibility. I have not used v17 for production at all due to all of its accessibility issues. Fingers crossed that v18 is truly fixed in that regard.
I really hope so, too. I’ve been adding accessibility features manually and it’s been an exhausting pain. For my company, any and all content must be Section 508/WCAG 2.0 (AA) compliant. So for me, this one thing being fixed would be huge for making content faster and thus justifying the cost of continuing to use Lectora.
Storyline and Captivate are still ahead in features, ease of use, etc. As for Lectora as a whole, I do like that it is the only major tool to publish HTML content that uses objects recognized by the DOM. Both Storyline and Captivate publish HTML, but not in such a way that JAWS recognizes the structure. So a definite plus for Lectora.
Agreed, and remains the only reason I’ve pushed back at every opportunity when the subject of using something other than Lectora at my company has been brought up. It’s less important to my co-workers who aren’t familiar with HTML/CSS/JS, but for me it’s the single most useful and defining feature of Lectora. I can generate decent tutorial slides for web quickly, and anything that Lectora can’t do “stock” I can do with my own code.
However, the HTML that is published is far from good, even for simple things. Adding a margin to a text object results in an TABLE object wrapping the text with padding on the TD. Unordered sub-bullets are not written as nested lists. So plenty of cleanup that could still be done there.
Absolutely agree 1000% with this. Looking at some of the code trying to figure out just why Lectora is breaking really simple HTML objects and/or what it’s wrapping my code in makes me want to cry sometimes. It’s not particularly obfuscated compared to other code I’ve seen (generally), but it is often hard to work with and would benefit the end-users if it were a bit more modular in design (a tall order for an existing product and code as old as Lectora’s, I know). I’d kill to be able to at least tweak or otherwise configure how Lectora handles integrating HTML object and associated code (e.g. I don’t need accessibility features added to my HTML object when it’s already got everything needed for that in its own code).
But I wonder what is the vision for Lectora? What is the direction of the tool, fixes aside? What’s the next major design move? (I don’t regard Vaast and CenarioVR as improvements to the core tool.)
This is the nugget right here for me. If Lectora’s going to coast and only release more or less maintenance updates with very minor new features for new release versions, it’s going to get surpassed by another product sooner rather than later. It’s going to be hard to play catch-up with the product that does if the current user-base starts migrating. I know I won’t be advocating for waiting around for Lectora to catch up if that day comes.
My goal is simply to make the best content I can with the least amount of work. Spending more time making sure Lectora hasn’t broken my custom code/fixing it than it took to write it in the first place doesn’t feel very productive, and there’s simply no way to expect Lectora to offer every single feature I’d like such that adding my own code won’t be necessary.