MobileRead Forums - View Single Post

daubnet · 09-11-2011, 05:17 PM

I like Sigil, and appreciate that you're openly discussing the future direction of it's development.

I see two ways of approaching this subject:

define a target audience. This is "who will use the app"
define "use cases". That's "what is the user's task"

I see Sigil as a tool, or set of tools. Choosing a tool mostly depends on the task at hand, which is why I'd focus on the latter more.

Let's use the "spell checking" feature as an example. Somebody whose workflow starts with a word processor and then exports the stuff to ePUB does not need a spell checker, regardless of the person being a "power user" or not. Somebody whose workflow does not include a word processor (like editing existing ePUBs) might have a need for a spell checker. Again, that is independent of the person's experience level.

I think the overall tasks people use Sigil for are these three:

changing an ebook to be the "way I want on my reader"
preparing an ebook to be released in stores
editing an ebook to serve as intermediate format in a chain (e.g. to use with KindleGen)

None of the above is something that Joe Average does today, but none of those tasks are so difficult that Joe Average couldn't possibly do it, given good tools. And please, if you come up with a fourth use case, go ahead and add it to the list. The way I see it, understanding what people want to do is an important step to making it a good piece of software.

Above general use cases can be split into a number of smaller tasks that may or may not be needed. Such a list of smaller tasks could look like this:

reading the book
Proofreading
edit content
edit metadata
Importing data (entire book, a chapter, or just fragments like images)
Exporting data (entire book, parts of the book)
edit markup (XHTML)
edit layout (CSS)
edit TOC (NCX)
compatibility checking
compatibility tweaks (may include any part of code, see 'Nook Color Cover' issue)
making sure an ePUB validates

This list is far from complete, and should be extended to more specific use cases like "assigning an ISBN to the book" or "making sure the eReader's font isn't overridden by CSS".

You may be thinking "reading the book" and "proofreading" should be the same item - no they're not. While proofreading does include the task of actually reading the book, it may also include spell checking, taking notes, and checking document structure. The point is: is Sigil meant to be used for proofreading purposes? If so, it needs a spell checker. If it isn't, then such a function is a waste of time.

I have my personal oppinions about certain features as well, but I think it is way more important to define what use cases Sigil is designed to handle.

Oh, in case you were wondering, I'm a software author myself (totally unrelated to ebooks) and am personally using Sigil to prepare ePUBs for public release.

09-11-2011, 05:17 PM	#65
daubnet Member Posts: 18 Karma: 1314 Join Date: Sep 2011 Location: Hamburg, Germany Device: iPad	I like Sigil, and appreciate that you're openly discussing the future direction of it's development. I see two ways of approaching this subject: define a target audience. This is "who will use the app" define "use cases". That's "what is the user's task" I see Sigil as a tool, or set of tools. Choosing a tool mostly depends on the task at hand, which is why I'd focus on the latter more. Let's use the "spell checking" feature as an example. Somebody whose workflow starts with a word processor and then exports the stuff to ePUB does not need a spell checker, regardless of the person being a "power user" or not. Somebody whose workflow does not include a word processor (like editing existing ePUBs) might have a need for a spell checker. Again, that is independent of the person's experience level. I think the overall tasks people use Sigil for are these three: changing an ebook to be the "way I want on my reader" preparing an ebook to be released in stores editing an ebook to serve as intermediate format in a chain (e.g. to use with KindleGen) None of the above is something that Joe Average does today, but none of those tasks are so difficult that Joe Average couldn't possibly do it, given good tools. And please, if you come up with a fourth use case, go ahead and add it to the list. The way I see it, understanding what people want to do is an important step to making it a good piece of software. Above general use cases can be split into a number of smaller tasks that may or may not be needed. Such a list of smaller tasks could look like this: reading the book Proofreading edit content edit metadata Importing data (entire book, a chapter, or just fragments like images) Exporting data (entire book, parts of the book) edit markup (XHTML) edit layout (CSS) edit TOC (NCX) compatibility checking compatibility tweaks (may include any part of code, see 'Nook Color Cover' issue) making sure an ePUB validates This list is far from complete, and should be extended to more specific use cases like "assigning an ISBN to the book" or "making sure the eReader's font isn't overridden by CSS". You may be thinking "reading the book" and "proofreading" should be the same item - no they're not. While proofreading does include the task of actually reading the book, it may also include spell checking, taking notes, and checking document structure. The point is: is Sigil meant to be used for proofreading purposes? If so, it needs a spell checker. If it isn't, then such a function is a waste of time. I have my personal oppinions about certain features as well, but I think it is way more important to define what use cases Sigil is designed to handle. Oh, in case you were wondering, I'm a software author myself (totally unrelated to ebooks) and am personally using Sigil to prepare ePUBs for public release.