But I’m not a developer!

Posted on: September 9th, 2010 8 Comments

I lack objectivity when it comes to programming. I enjoy it. Programming is problem solving. It almost always includes a reasonable explanation. Programming involves building things, and fixing and refining the things that you build.

I am concerned that for myself, and as a company, a lack of objectivity when it comes to designing systems which lay users can feel comfortable customizing, constitutes a significant blind spot. There are, I’m told, plenty of people who are not developers.  There are those who may feel put off by our recipes for customizing your ePublisher projects; creating folders, copy and pasting code, and so on.  I would like to hear from you. In particular, I’m interested in how you feel about ePublisher customization. Do you customize? Is the process intuitive? Are there things that you would like to customize, but you find yourself protesting, “But I’m not a developer!” when you find out what’s involved.

Tags: ,

8 Responses

  1. Dave Truman says:

    I would say it’s analogous to how developers feel about writing (documentation, poetry, prose, etc). Some enjoy it, some hate it. Of those that like it, some have some knack for it, some don’t. Of those that have some knack, some have actual learning, but most don’t (and since it’s not something you do every day you don’t really “develop”).

    I think it’s too open-ended and “code level” for many writers, who are used to GUI-based tools to accomplish their tasks. (However, I can’t imagine a GUI that would enable you to customize what you can with ePublisher.)

    For me, personally, I think the customization process is okay, I can handle it. I’m comfortable with folder hierarchies, copying base files and editing to customize. But while I’m comfortable with editing existing code, I really can’t create brand new code myself in any reasonable timeframe (which you no doubt know from my various emails to you over the last while).

    Anyway, hope that helps!

  2. jwiles says:

    Thanks for the feedback Dave. You say that you can’t create new code in a reasonable timeframe. I’m curious if that’s due to time limitations you have, or due to the complexity of writing custom code for ePublisher?

  3. Dave Truman says:

    Mainly it’s due to lack of training and experience in this type of coding. I don’t have a fixed time limitation, just my sense of “I’ve spent enough time trying to do this, gotta move on”. And, sure, ePublisher’s complexity is a contributing factor, but I know it’s necessary to enable what it does. (FYI I’ve watched and reviewed every article or webcast you guys have done on customizing ePublisher (exept the latest on debugging XSLT).)

    ..
    There’s a bit of a thread here with one of your previous blogs on JScript vs XSLT customizing. If it helps, I would probably find JavaScript/.NET based customizing similarly challenging, for the same reasons.

  4. Sara says:

    *Do you customize?

    I customize on a basic level. I need to be able to customize the links in my output, and I need to be able to change the appearance of the topic “footers”. I also customize the .hhp file in Help Builder to adjust the default topic, window title, etc. Learning how to do this effectively was actually quite a challenge—it wasn’t simply a matter of making a few tweaks to the formatting (like maybe you would see in Microsoft Word) and ending up with an output that you would expect. It was a time consuming research process to find out what files I needed to adjust to perfect each aspect of the final output.

    *Is the process intuitive?

    When I first started working in ePublisher, I did not find the process intuitive. I felt I spent as much time researching how I could adjust the Page.asp to work the way I needed it to as I did actually generating the output or building a project. This is because I had no formal training in any kind of coding or “behind the scenes” files. I found myself wishing on more than one occasion that some aspects of the customization process could be more GUI based. For example, why isn’t there a window that enables me to define how I want the search features to work in my Microsoft HTML Help 1.x output? The first question I might ask is this: is this simply a limitation of my output type, or is this a burden of missing GUI features? I guess as someone who just wants to quickly create stationery, customize it, and come out with a customized help file, I haven’t spent much time researching file types and limitations.

    *Are there things that you would like to customize, but you find yourself protesting, “But I’m not a developer!” when you find out what’s involved.

    Yes. As a department, we really wanted to move our mini-toc information so it would appear below the help content—but the only way we could imagine doing that was by changing information “behind the scenes”. We simply gave up on it because we didn’t have the research time to dedicate.

  5. Jesse Wiles says:

    Sara, thanks so much for your feedback.

    The first question I might ask is this: is this simply a limitation of my output type, or is this a burden of missing GUI features?

    In the case of Page.asp, I think this is probably “a burden of missing GUI features”. Some customizations, by their nature, require coding. For instance, the positioning of the Mini-TOC customization you describe requires custom coding. We have pushed many of the customizable aspects of Page.asp into the Target Settings and Page Style options. Items such as defining “Company Information” (probably more accurately labeled Header/Footer) and positioning Breadcrumbs, are available through the GUI.

    Thanks again for your comments. This kind of feedback is very valuable to us.

  6. Marcus Baake says:

    I personally am comfortable with the amount of “development work” for customizing ePublisher, but especially when customizing the XSLTs in the past I could have needed a better documentation of the different namespaces and extension objects, e.g. “wwproject”, “wwdoc”, etc.. When customizing I often had to do some major research myself (by inspecting various XSLT files and looking at the way the different objects are used there), while a good documentation would have spared me a lot of time.

  7. April Mills says:

    I am a technical writer, not a coder. This means that I need a tool that is easy for me to use to create and maintain online help content.

    Tech writers explain the things that coders build – it’s a different skill set. Besides, if I were a developer, they’d have to pay me more!

    I’m not having very much success with WebWorks – it allowed me to bring a .doc in, but won’t let me work with it because it’s a trial version. I can’t publish it to a company server because it’s a trial version, but I can’t work with it either, for the same reason.
    Frustrated!

  8. jwiles says:

    Hi April,

    Sorry to hear you’re having trouble. Please come to the next Study Hall and we’ll work to get you up and running.

    Jesse Wiles

  9. BobbuBrowne says:

    Hello! Cool post, amazing!!!

Leave a Reply