Quote:
Originally Posted by phillipgessert
Describing an ebook as a visual product is kind of a perfect crystallization of what's wrong with WYSIWYG. With WYSIWYG, you get folks doing all sorts of arbitrary things that are semantically meaningless but "look right." You have to properly describe the structure of your document, something that is nearly never done by folks using WYSIWYG.
That's why most of the most lauded WYSIWYG apps find success mainly by kneecapping customization options, something that ironically usually causes their users to cry about their exclusion. Can't have it both ways.
|
AMEN! This is exactly the problem with so-called WYSIWYG apps, whether it's Word or iAuthor. Either the developers ensure that the product "infers" what the user wants and then applies it (Word) or they crud it up with so much godawful code that the end result is unreliably usable later (iAuthor's incredibly bad ePUBs, which only work in the Appleverse of iBooks. I mean, iAuthor is being d/c'ed, by Apple. That should tell you everything you ever wanted to know about this very type of app.)
Quote:
Originally Posted by DiapDealer
We ran into that as well. People not only wanted Book View to create the code for them automatically, they also wanted to complain that BV wasn't generating the code they way they WANTED it to be generated. I can't count how many complaints we got about people not liking the perfectly valid/compliant code that was being generated by Book View!
|
Yes, that too.
It's true that you can't open ePUBs in AWP, or Jutoh, et al. Perhaps, given that all these products are aimed directly AT the "WYSIWYG" customer, people should stop and ask themselves why that is; why something that they think is perfectly simple should be apparently so tricky.
I would point out for those whingeing, that if the ability to open ePUB A in an editor that's also WYSIWYG is so crucial--open the ePUB with Calibre, save it as docx and then open that in Jutoh or AWP or whatever. In AWP, you don't open the resulting ePUB and edit it, if you aren't happy; you simply revise the source document and build another ePUB.
AWP and Jutoh, in fact, have taken the "the writer/editor doesn't know bupkus about writing code" view, to the nth degree, assuming that all edits can and will be done, in the word-processing file. Which seems the obvious method, given what's been said here. Right? I mean, if learning to edit the code is such a problem, then they have taken the correct path. If you don't like the ebook result, from your file, you don't get your hands dirty in that file; you simply go back to your source, make your changes and then export a new eBook. That makes perfect sense to me, given the apparent unwillingness of the user to learn HTML/CSS. Why would it work any other way?
Or,
pay for Blue Griffon, amirite? Doesn't that have the functionality that used to be something like BookView?
For only 195 EU? (The user manual is
only another 7.95 EU,too.) Such a deal. It has exactly--exactly--what's being requested here, yes? So...happiness is! They even have a downloadable trial version, for those of you that are so distressed over losing Sigil's BV and, for some reason, want to constantly complain about it instead of simply downloading one of the older versions WITH Bookview and using that.
OR...here's a shocking idea--open it with Sigil and then learn to use and love PageEdit.
The options are pretty extensive, really.
Hitch