Installing PubCoder

I’m leaving for the USA in a while for a holiday, so been busy preparing for that.

Why this post about installing PubCoder?

In my last post, I determined the first of 10 heuristics/criteria for choosing a tool that helps you create and publish ebooks. When critiquing an ebook creation tool, I ask:

  1. Does the tool support effortless writing?

I can’t answer that question before installing PubCoder. Also, the installation process is a herald of the kind of interaction design decisions designers made about the rest of the application. So if I struggle to set it up, I’ll likely struggle to get into it.

I’ll be using PubCoder as a tool to create fixed-layout interactive ebooks that can be published on a variety of platforms. I suggest checking out Non-Fiction Fixed Layout eBooks from my mentors, eBook Architects to get a sense of how complicated it can be to make these kinds of books. Which is why ebook designers ask a hefty fee for making them.


Installing PubCoder: A “meh” experience

Here are the screenshots and my thoughts about installing PubCoder as comments. My verdict so far is that PubCoder’s installation process is needlessly complicated, requires an internet connection, and leaves the user without much guidance at first startup.

However! I did play with PubCoder after installing it, and am finding a lot of promising interaction design decisions which, I think, will prove it to be a powerful tool for creating fixed-layout or interactive ebooks. But that’s for another post.


1. Requiring access through your computer’s safety net, the firewall, makes installation difficult, but isn’t the developer’s fault. Most users should be familiar with this dialog, and know what to do. 


2. First annoyance, a random crash. Errors are hard to explain to users, and the reassurance that “you will be able to send a crash report” is fine, but still doesn’t help the user feel in control. Why not add an option to send a crash report within that error message?


3. Requiring users to sign in online all the time is an understandable security precaution, but it’s also an added step. The more steps it takes to install software, the less likely users will be to complete installation (totally anecdotal, not a rule that I know of). 


4. Do you really need all this information? If company isn’t required, why have that field there at all?


5. A decent captcha. 


6. The verification email was pretty easy. Yet another step, though. 


7. Alright, one month to go! 


8. Confirmation that you may have to be online at all times. 


9. All done! Time to look at example ebook projects. 

Beating the drum for DRM?

I finished marking some PUB310 semester tests. In one of the questions, I ask students to suggest criteria that would influence their choice of ebook vendor. A criterion that is often used is the use of digital rights management (DRM) – or at least, the option of providing DRM for titles. According to the memorandum, this statement is part of an acceptable answer.

Given my personal feelings about DRM in general (feelings that are often compounded by Steam), this criterion worries me – especially when presented as a quick solution for  protecting intellectual property. Frankly, I want them to realise that selecting DRM as a default option without considering the effects of that choice is a very bad thing.

In Beating the drum for DRM?, Appazoogle’s Leah Thompson summarises discussions for and against the use of DRM. Leah shows how the Triangle of Fraud – a model used to investigate accounting fraud – can be used to consider the relationship between DRM and piracy. One of the components of this triangle is rationalization: ‘I already own the book version.’ ‘It’s not worth as much as they’re trying to charge.” The other two, pressure (high prices) and opportunity (cheap bandwidth), might imply that lowering prices can play as great a role as reducing opportunities to pirate (such as litigation or access restrictions).


Don’t forget e-ink! An African’s perspective.

I’ve been advocating the use of ebooks among publishers, librarians, educators and developers for six years now. One of the things that I often need to explain is the difference between an ereader and a media tablet. That’s easy; I just focus on the hardware and software differences.

The hard part is explaining the usefulness of each, because these are simply two currently popular ways of packaging digital media – indeed, packaging knowledge. It really doesn’t matter what the container is – if you assume that the container has an effect on the content.

If we agree that the container has an effect on the content, it’s not surprising that people tend to downplay the value of ereaders, especially ones that use an e-ink display. It is as if a display that isn’t full colour, doesn’t show HD video and doesn’t support fluid screen interaction is less valuable than others. Feature-rich smart phones and media tablets seem the best suited as carrier of information, because they’re the Ferraris of digital media consumption.

Well, we don’t have much fuel. Also, not everyone can afford a Ferrari – nor do they have to. E-ink is cheaper, more durable, consumes less power. Hence, containers that use this type of display are cheaper, more durable and consume less power. If these devices don’t affect our relationship with reading, why downplay their value?

Also, we’re reading away from the desktop. Our interaction with digital media occurs everywhere. This implies that we can go outside again, where there’s sunlight. Here, the container does affect the content for sure. Have you ever tried to work on a backlit display in sunlight? E-ink doesn’t have that problem. 

I have a media tablet, too. I use it a lot. This post isn’t meant for people who can afford lots of gadgets – we have a choice. That’s why I wince every time someone looks at an e-ink  display and summarily dismisses it as a tool for reading.

Should displays that are both transmissive and reflective become popular and affordable, this would invalidate my point. Initiatives such as Worldreader and Paperight indicate, however, that we cannot only look to the developed world for guidance in this regard.

PUB310: Publishing in the digital environment

In 2006, our department needed someone with a background in multimedia/digital media to teach our publishing students, so I took up the challenge. I started teaching this course the year Amazon released its first Kindle – and what a ride it’s been!

Here’s an overview of the course, aimed at people who want to contribute to it. We plan to restructure the course for 2012 (since we’re resurrecting a postgraduate version in 2012, too), so this is based on the 2011 curriculum.

Please read the following if you’re here to help: [1][2][3]

In this overview, I deliberately keep some things in that need to change in order to demonstrate the challenges of curriculating a course in such a rapidly changing industry. I also have some [ideas about changing the way we teach the course, which aren’t necessarily part of the curriculum yet].

Continue reading