I think all RPGs should be html.

edited November 2009 in Story Games
Books are great for linear reading, but for reference, hyperlinked text in the same web browser I already pretty much live in is much more convenient. Why do designers want to force their page layouts on me when it's the *content* that's what matters?

Comments

  • I agree on this one nowadays. Pretty obvious, really.
  • But you'd have to pull your laptop out of your arse first, though.

    I still prefer books, myself.
  • I'm not sure that using HTML as the primary format for game writing is all that desirable. Yes, links are nice, but I've seen far too much hypertext where the ability to link was used as a substitute for the hard work required to organize material linearly, resulting in documents without a fixed reading order. In my experience this results in material that is harder to absorb and more likely to be ambiguous.
  • Surely you mean XML. Or better yet, a customized flavor of SGML just for roleplaying games, right?
  • edited November 2009
    I think all RPG products should suit their content. And their customers.

    And HTML will only do that for some. Just like boxed sets. Just like books.
  • I considered that when I wrote my reply, Jason. The weakness of XML or custom SGML is that you'd have to choose a document format that is interpretable by your delivery software of choice - so either that choice is XHTML so you can use the ubiquitous browser Ron mentioned, or you're back where you started with PDF files, needing a separate program for accessing the material.

    (I hear wild legends of self-created custom XML document declarations that some browser might be able to understand, allowing you to invent your own XML markup and program its browser display as well. Maybe in the future.)

    Other than that, I repeat my prophecy from the box thread: the games that benefit from long, living texts will become electronic in the future, with HTML being a quite strong and already well-supported format, while short, solid games will benefit from more productization, becoming like boardgames. Books will continue to be the delivery format of choice for a certain subset of the audience for practical or aesthetic reasons, but their production will become a specialized sidenote - the electronic form will come first, and books will be spinned from that format by various means ideally light on labor. So in that sense I support Ron's claim of "should": we indeed should start writing our books with the primary attention on electronic publication; this will allow us to leverage the full benefits of the electronic medium while causing a negligible impact on our book production capabilities. Already a smart workflow will make producing a book almost trivial after a a correctly typed electronic text is in existence.
  • Leveraging client side databases in HTML (such as HTML5's Web Storage spec or google gears) to allow the players to annotate their own copies with new parapraphs, notes, cross references, etc would be a killer feature. It could probably be packaged up in a generic JS file that publishers could just drop into the html bundle.

  • I had this in mind when I put Anima Prime on Drupal. It's about two versions behind at this point, though, due to the pain-in-the-ass-ness of updating all these different pages. It's much easier to work on one big Word document where I can jump around, split screens, etc. But I might still update this once the editing is finished.
  • As an example supporting Eero's prediction, I've planned my game to principally exist as a wiki, and only secondarily in a book.
  • I think HTML is a pretty good choice for the electronic version of any game. Certainly about a million times better than PDF. I've already written extensively on this topic though so I'll leave it at that.
  • Posted By: Jason MorningstarOr better yet, a customized flavor of SGML just for roleplaying games, right?
    Story Games Markup Language?
  • Posted By: FigureFourStory Games Markup Language?
    Definitely! That won't be confusing at all!
  • I have used xml in the form of DocBook, for technical documentation. It works well, and does handle outputting to variety formats. http://en.wikipedia.org/wiki/DocBook

    Now could it handle any of the artistic layouts? I doubt it.
    Posted By: FigureFour
    Story Games Markup Language?
    No need, call it Pin and Paper Game Markup Language. We would only to add a few things to DocBook. Mostly to tag game mechanics semantics.
  • Posted By: Jason MorningstarSurely you mean XML. Or better yet, a customized flavor of SGML just for roleplaying games, right?
    If someone started a project to create a standard semantic XML schema for RPG texts, and an associated stylesheet, I'd participate.

    Paul
  • I'd love all HeroQuest/Glorantha setting material to be in one great big wiki. Instead of on a bunch of different wikis and sites, and spread through a zillion books in thirteen different editions.
  • edited November 2009
    Posted By: Eero TuovinenThe weakness of XML or custom SGML is that you'd have to choose a document format that is interpretable by your delivery software of choice
    This isn't entirely true. You can, for example, supply a URL to an XML document such that, when loaded in a modern browser, the XML gets transformed by an XSL transformation into an HTML page automatically. To the user, this would look exactly like they just clicked a link to an HTML document (though slightly slower). An "advanced" user, however, would be able to use the XML source for his own nefarious purposes.
  • Well, yes. We're certainly on the verge of universal, entirely transparent information management. Already we can work internally with some extremely logical workflows today. I'd still pick html (or xhtml, to be exact) as my delivery format at this point, but as you say, we can certainly use general xml internally.
  • So only people who can afford mobile computing devices should be able to play RPGs?

    ...and only people who can actually program (or whatever you call managing HTML if it's not strictly 'programming' per se, before that nit gets picked...) should be able to write/design them?

    -Jim C.
  • edited November 2009
    In looking into this, it turns out that XSL transformations are not necessary: you can now apply CSS directly to XML. I threw together a very rough sample of this, using the first few pages of Wushu Open and an XML schema that I pulled out of my ass.

    See the sample here. Use "View Source" to see the raw XML. This works on the latest Firefox. I haven't tried it on others.
  • Posted By: Jim CrockerSo only people who can afford mobile computing devices should be able to play RPGs?

    ...and only people who can actually program (or whatever you call managing HTML if it's not strictly 'programming' per se, before that nit gets picked...) should be able to write/design them?
    Yeah, Jim, I sure can get behind that. If you can't afford an ebook to read the html on, or any other computer, or the printed book version printed from the digital file, or a sheaf of paper to print/copy the text on yourself, then you shouldn't be able to buy (not play, note) a game text. Likewise, I'm firmly in the camp that if you can't write HTML, or use an authoring software like Microsoft Word, or pay somebody to type your text into a computer, you shouldn't be able to write a RPG intended for mass release.

    All instances of "should" in the above should of course be read as expectations on my part. If anybody manages to confound these expectations, do let me know - Jonathan Walton has speculated about orally transmitted roleplaying games, I think, but aside from that I've yet to see any ideas for how to avoid selling game texts in textual form.
  • Jim - Have you seen the price of books lately?

    Although what I really should have said was all RPGs should *also* be available in html. Again, I prefer books for reading, but I'd rather do random access reference stuff in a web browser.
  • Posted By: Ron HammackI prefer books for reading, but I'd rather do random access reference stuff in a web browser.
    Agreed. Books are better for learning, something dynamic, indexed and searchable would be better during play as a reference. I'm not convinced that's a website though.
  • edited November 2009
    Hey, Lester, that's superb.

    My one doubt about the XML is whether we should divide things into chapters. I'd personally have a [chargen] tag, a [conflicts] tag, a [flavourtext] tag and so forth. Perhaps not exactly those tags, but I'd use tags to indicate what the information was.

    That's the sort of thing we could argue about all day, of course.

    We need Clinton in on this.

    Graham
  • I like RPGs as books.

    HTML (or whatever web thing you guys decide on in this thread) is great once I've already bought and digested a game. I like downloads, and I like being able to grab chunks of text when I need them to run/play games.

    But I really like a BOOK to buy and read and carry around. And I'm not being all retro or book-fetish-y. Books are cool, and relatively cheap, and everyone understands how they work, and you can have certain expectations of a book you can't have of an online product.
  • Hey Brian, compliant markup+ Prince + printing and binding option of your choice = hard copy. That's one way it could happen that keeps total control in the user's hands.

    (I like books, too)
  • Why HTML and not PDF?

    I personally like the design control I get using Adobi products. I did some HTML coding ten years ago and it felt like computer programing in the 70's and 80's. Sure I could do it but not and make it pretty.
  • PDF can be made somewhat prettier at this point, but it is also much more annoying for habitualized computer users from an usability point of view. Opening pdf files is much slower, much processing power is spent on emulating legacy functionality for paper reproduction purposes, layouts are limited to paper-like concerns and reformatting the material for different purposes is nigh impossible. These are not major concerns for occasional computer users who do in fact benefit from the strengths of pdf files, but for power users they are deal-breakers. I've myself experienced the phenomenon where I idly click on some moderately interesting thing on the net and actually cancel the operation when I see the computer go into pdf opening sequence - I often don't have the time and the patience to have the computer torture itself with a pdf file like that. It's a clear usability threshold compared to html or other immediately browser-interpreted formats.

    The deeper, long-term benefits come from the superior flexibility and usability interfaces that text formats (including HTML) offer. Copying text from the file never becomes an issue, screen size of the end-user is not a problem, updating the material is trivial, transforming the entire file into something else (such as pdf) is a one-click process and so on. The workflow is simply simpler and more robust, although admittedly we achieve this by losing much of the paper-publishing functionality that pdfs offer, such as total typographical control and such. I estimate that these losses will weight less in the future as people get used to the information processing point of view: as IT professionals already know, data and its presentation are two different things, and greatest powers are available only when we manage to separate them and flexibly repurpose the presentations to always be optimal for current needs and purposes. This viewpoint is still foreign to the majority population, but I expect that the benefits will trickle down in time and make abandoning the pdf paradigm in digital publication all the more alluring.
  • Can HTML be read on ebook readers (Kindle etc.)?

    To me it seems clear that the ebook reader will merge back with the computer pretty quickly so this may not be an issue for long if it is an issue at all.
  • One of the great challenges facing traditional RPGs not based on licensed properties is how to enable an enthusiast and prospective GM to hook the interest of players. The GM's enthusiasm for a setting doesn't often translate to player enthusiasm for reading bigtastic setting texts. But, given a richly semantically tagged XML text of the game, the GM could choose a specific location and timespan for his campaign and use XML tools to pull a digestable chunk of text for hooking players. A little geography, maybe a couple of creature descriptions, a snippet about the war between the Vrunch and the S'gart, and suddenly a player is saying, "Hey, I want to play a breeder of war mounts for the Chodox."

    Paul
  • "Although what I really should have said was all RPGs should *also* be available in html. Again, I prefer books for reading, but I'd rather do random access reference stuff in a web browser."

    That's a much less provocative statement, and one that I don't have a problem with. The multi-platform releases that are going on these days certainly seem like a good thing for users who prefer different formats. I have a personal and professional bias towards print, obviously, but I also understand that some functions of particular games are much better served by computers (the ddi stuff has almost entirely taken over my DMing time in my D&D 4e game, for example).

    And yes, SOME RPG books can be 'expensive' (though most story games of the type we're talking about here are about the cost of a couple movie tickets give or take a couple of popcorns), but they're also portable and durable in a way that a Kindle or Netbook aren't necessarily. If I drop my backpack, or it gets stolen, or I spill a soda, or I want to hand it to someone else for a couple days to read through, a paper book is better for ALL those situations; I'm only out the one work, and maybe not even then, as books can take certain kinds of trauma better than electronic equipment, and not my entire library. But having more than oen version availabl for different situations, that's so clearly a viable idea that it's being adopted pretty universally across the industry without a lot of hand-wringing or hard pushing.

    -Jim C.
  • That's a neat idea, Paul. Maybe code up your XML so you have nested tags like < setting >, < teaser > and < detail >. You'd need a reader or an interface that could parse that but you could pretty trivially extract, say, all the teaser text (plus associated images) into a player's handout type of thing.
  • Posted By: MatrixGamerCan HTML be read on ebook readers (Kindle etc.)?
    Yes. At least some. And converting from HTML to e.g. Mobi is trivial.
  • Posted By: Jason MorningstarHey Brian, compliant markup+Prince+ printing and binding option of your choice = hard copy. That's one way it could happen that keeps total control in the user's hands.
    I do like being able to make hard copies for myself. I do that now with PDFs or online texts. But those things are different from printed books, to me. Although I guess they may be less different in FutureWorld(tm).
    Posted By: Paul CzegeOne of the great challenges facing traditional RPGs not based on licensed properties is how to enable an enthusiast and prospective GM to hook the interest of players. The GM's enthusiasm for a setting doesn't often translate to player enthusiasm for reading bigtastic setting texts. But, given a richly semantically tagged XML text of the game, the GM could choose a specific location and timespan for his campaign and use XML tools to pull a digestable chunk of text for hooking players.
    That sounds cool. I would dig that game. (And I absolutely agree that the bigtastic setting text = FAIL).

    But with most players I know, handing them a book is the best way to go to kindle interest. Once someone is already on board, they definitely want a PDF or link they can check out, but if you're trying to get people excited, giving them a brief and enthusiastic pitch and then handing them your copy of the game book is more effective. (Depends on the person, of course).

    Also, the thing you described doing sounds like it might be beyond people without technical skills. (I say that not in a "you need to check your privilege" kind of way, but in a broader, practical sense.)

    I'm not trying to be all Luddite. I see a lot of benefits from HTML games, but not as many as from books.
  • edited November 2009
    I think a point that might be getting missed here slightly is that a few people in this thread (myself included) are really talking about meta-formats. That is, the question is not "what is the preferred format" as much as it is "what kind of format could you release a game in that could be easily converted into many preferred formats automatically".

    Sufficiently rich XML is one format that would fit the bill. Almost noone would read this form natively, but tons of tools exist for turning it into PDF, HTML, Word docs, whatever.

    There are formats that can do this as well, but PDF and HTML aren't it.

    (Interestingly, the subject of the "parody" thread of this one that was started is actually closer to this point than the subject of this thread is.)
  • There's a wonderful cognitive trap in the phrase "sufficiently rich XML."

    yrs--
    --Ben
  • The advantage of books over HTML that nobody has gotten around to mentioning is that they are read as continuous works of prose. So for game authors who think of their work as being worth reading because it's well-written, rather than just because it's a repository of information, HTML is actually an impediment to successful communication with one's audience.
  • Posted By: lordgoonThe advantage of books over HTML that nobody has gotten around to mentioning is that they are read as continuous works of prose. So for game authors who think of their work as being worth reading because it's well-written, rather than just because it's a repository of information, HTML is actually an impediment to successful communication with one's audience.
    That sounds like a disadvantage to me. Game authors who think that the writing is more important than the game are in the wrong line of work. Good copy is always important to engage readers regardless of the format, but game books written as novels aren't very useful as games. The format needs to serve the message and then the writing serves both, not the other way around.
  • Posted By: WordmanThere are formats that can do this as well, but PDF and HTML aren't it.
    Good XHTML could definitely work that way, especially with a good microformat. I think that would work better than another XML definition.
  • edited November 2009
    Posted By: Ben LehmanThere's a wonderful cognitive trap in the phrase "sufficiently rich XML."
    Design of a system that did this is certainly way harder than it sounds (even if you think it sounds very hard). One path through this sort of design is to come up with a fairly robust and wide-ranging set of targets, and see how various choices would work in building them.

    I can only think of three basic notions at the moment, though.

    1) Something like a single page HTML file. Very simple. Very limited, but still useful. (There are some "variations" to this idea, such as a very simple ebook format or something, but basically any rendering where the result is a long stream that doesn't particularly worry about page breaks, display size and so on.)

    2) The obvious rendering into a PDF book. Harder than it sounds because the author may care a lot about certain text appearing on a certain page (or, sidebar X being on the same page as rule Y, and so on). (I haven't used XHTML in a while, but my recollection is that its notions of pagination sucked.)

    3) Something like a "hypertext reference database", where the data is split into small "entries" tightly linked together. The result might be a directory of linked HTML files, a .chm file, or a more advanced type of ebook. (I doubt XHTML would be very good at anything but the most rudimentary form of this. Take a game like Spirit of the Century, for example. In a real reference system, you might want to treat, say, a section of text that describes a Stunt as being distinct from some other type of section, allowing you to process Stunts in some special way. Without some very hacky tricks, one div tag in XHTML would be basically the same as another.)
  • So the skill set to publish games moves on.

    One of the challenges in publishing is learning the skills to do it (or you are at the mercy of someone with the skills). Since I've been gaming (1976) the skill set has changed three or four times. With the constant move forward of technology that will only continue and speed up. There comes a point where you stop trying to be leading edge and pick and choose from what has been made easy and use that. I don't think that is Ludditism (I don't mind if the world plows on ahead of me) it's just a recognition that I could spend all my time learning the newest XML or I can make my games (in my case PDF off of Adobi products).

    I've very interested in ebook readers and how they will work but I'm unimpressed by the Kindle. I want an 8.5x11 reader that can show whole PDF pages in the layout the designer wants it to be in. Graphic design is important to me. The art communicates more than words. Honestly HTML sucks for that.

    I know I'm not the target audience for game sales. It's mainly younger folks who buy more. They undoubtely are more tech savvy.
  • It's clear that different people have different requirements. I read a lot more stuff online than I used to and have come to enjoy the advantages of reading online. I downloaded the Kindle app for my iPhone because it was free and there were some free books I could use to try it out. I was sure I would hate reading a book on my phone, but I wanted to use actual evidence to support my diatribes on why reading books on a phone was a stupid idea. Instead I found that I love it and have proceeded to read several more books on my phone. (I am troubled with the way Amazon monetizes ebooks, though, but that's another topic. I also have an irrational love of collecting physical books and I wish publishers of novels would do what some game publishers do, where you get an electronic version with the purchase of the physical text. Crap, I'm going way off topic...)

    The way I read reference books (what game books essentially are) is very different from the way I read novels, though. I could see doing an initial read through of a game book on the iPhone, but then to refer back to it, I'd want a bigger screen, more ready access to the index and table of contents. For me, I think the various markup languages that already exist are fine for displaying the electronic versions of such books, but I don't think the device exists yet, at the price point that would make it reasonable, to make me want an electronic version at the gaming table rather than a print version. (I already own a laptop, and the price-point issue isn't such a problem because the laptop does so many other things that it's not just an expensive ebook reader, but I don't like that a laptop doesn't lay flat when it's open. Yes, there are tablet PCs, but I'm a die-hard Apple fanboy...) I think I would need something like the Kindle DX, but color, and with a touchscreen. While I'm at it, I would make it so it opened up book-style, so it had two screens, so I could always have an index open on one screen and read text on the other. I'd like this to cost about $100. Please let me know when this is ready.
  • The device you describe costs something like $1500 at this point (at least with digital paper; probably much cheaper with a traditional display), John, so there's still some ways to go. Still, that's the way of the future, so let's all futurists just be patient.
  • edited December 2009
    I'll admit I didn't read line-by-line (I work with SGML and XML--I'm not here to work), but I'm surprised no one's said "copy protection" yet. There's absolutely nothing you can do to copy protect HTML (SGML, XML) without some kind of hardware dongle and (crackable) client-side scripting.

    At least PDFs can be sold with Passwords To Open, which will give you an audit trail once they hit the file sharing sites (assuming you provide a unique password per sale).

    Annnnd, I know this is an aside that's not totally relevant: many projects don't care about profit or the protection of same. When I have free/CC project, I DO put them in HTML.
    -----
    It is entirely possible to deliver HTML with all the graphical "zing" of a printed book, folks--that's a dead-end objection. One might not be able to do so with Totally valid, Proper, Approved, Structured, Transitional HTML (4.0), but one can do so with Hacked, Table-Formatted, Fix-Scaled, Semi-Scripted HTML. And that HTML can even be made to print on a page neatly (it can! I SEEN it, up in the hills! I SWEAR!). Or you can do all the XML(DTD) -> XSL -> HTML/PDF/MSHelp/Kindle/etc/etc pipeline. With the click of a button, once you have it setup (you can! I SEEN it, up in the hills! I SWEAR!).

    Problem is, most of the infrastructure to do that easily (i.e. not you hand-coding cranks with your LaTeX--you boobs! (pun intended)) costs thousands of dollars in software and setup time (and testing). Unless you find a bunch of volunteers, free open source software, and patient print providers. I've never found more than one of those three, in my experience....
  • All sorts of things can be done, David, but I don't that that we should be singing the praises of systems that are still clearly incomplete - let's rather be realistic and confess that while HTML (XML, whatever) can do all sorts of amazing things, doing those things is at this point the domain of expert web programmers and not any sort of reliable routine. Also, I don't think that HTML can do "the same things a book does" broadly speaking, the gulf in publishing traditions is just too great. I invite anybody who thinks otherwise to try to create a bog-normal tabulated list in both HTML and a normal layout software. It makes much more sense to treat the screen as an entirely new medium, rather - it can do amazing things, but those things won't map 1:1 on things that have been done on paper in the past, and we'll all have less in the way of desperate annoyance ahead of us if we don't insist on aping the paper layout in what we do on the screen.

    As for the lack of protections in HTML, I guess I don't see that as a problem due to how I don't see a future in copy protected culture industry in the first place. I wouldn't place any bets on which will be the first to go, the paper book or the whole concept of paying for content. Whichever it is, the other one won't be far beyond. I see the window of opportunity in digital paid content to be so narrow that anybody trying for it as anything but a transitional thing will probably be sorely disappointed. Better to hone up our publishing models into something that can withstand universal piracy and eroding public perception for the justification of copyrights. Trying to prevent piracy becomes less profitable every day.
  • Posted By: Eero TuovinenI don't think that HTML can do "the same things a book does" broadly speaking...
    I think I said, "It is entirely possible to deliver HTML with all the graphical "zing" of a printed book," which is not the same thing. I am confident that I could, with not too much trouble, layout any RPG you care to name, in HTML, page-by-page perfect. (Whether or not aping the print medium is worthwhile is neither here nor there--it all depends on the customer's priorities.) Perhaps I am more skilled than the average bear, but I could even *hand-code* that, not using anything but a good text editor and FTP. If I am allowed other DTP tools, especially those with pixel-precise layout paradigms, I could do it a bit faster, for sure.

    But the thing is: If I start with a dedicated *print* DTP package, I can not only deliver a PDF (or PS) to my print provider, I can ALSO (with maybe some post-production) deliver an HTML version. And a high-functionality PDF for screen use (assuming I can use Acrobat), with a different page layout template and some mouse clicks. AND I could push out to plain text (for old-school eReaders or "bare bones" rules for reference/searching).

    Point being--the file format is sort of irrelevant to aesthetics. It IS relevant to delivery channel(s), usability, integration with other tools (e.g. a character database built from filling out a PDF form), and protection. Ron's OP is mainly (it seems) focused on usability.

    I'd also claim that I can replicate any kind of vanilla HTML site (i.e. not heavily scripted) in a PDF. Recall that PDF--being predominantly vector-based--scales to fit a screen (or a page) very nicely, whereas I've not used a browser that does so, for all sites (but, yes, one can build a site to do "full window scale" with the right markup). That's another plus in its column, compared to HTML.

    Conversely, why deliver anything remotely approaching print format, online? An "HTML RPG" should include (at the least) all sorts of character or situation generation tools, cookie (or HTML 5!!!) client-side data storage (e.g. those generated characters), Fortune mechanics tools, state maintenance and update functionality, etc, etc, (i.e. whatever common "rolls" and "notations" and "statuses" the game uses). HTML's interactivity, especially with scripting, is a couple or orders of magnitude more functional than just 'make it searchable and cross-referenced with hyperlinks.' AND, if you use the full spec, you can even make it print out mostly like you'd want it to, for a print provider (I'll admit I'm rusty on all those print controls, beyond placing page breaks so lines don't get clipped by dumb RIP engines).
    Posted By: Eero TuovinenBetter to hone up our publishing models into something that can withstand universal piracy and eroding public perception for the justification of copyrights. Trying to prevent piracy becomes less profitable every day.
    And that's why I was worried about derailing--protection and medium are linked, BUT discussion of an ideal medium for presentation of RPG content is orthogonal to protection. Another thread (or resume one of the several existent)?
  • Posted By: MatrixGamerSo the skill set to publish games moves on.
    As a graphic and web designer who does both at times for money: you'll have a much easier time teaching yourself HTML than teaching yourself layout. You can learn HTML in an afternoon. You can learn layout in a few years. Portraying this as merely shifting skill sets seems to miss the more important point: the skill set has become much, much easier and more widely available.
  • My experience is somewhat different, Jason - and I've done both of these things for money. Looking at it from the viewpoint of complete projects, it's not enough to know HTML; you also need CSS, Javascript and probably a bit of server-side programming and databases for a modern website. That's not a small skillset. Learning about typography, right workflows, color management and all that not a small thing either, of course, but then I wouldn't characterize either of these domains small - they're both so deep and wide that you can get into them as deep as you ever wish. Just like you can make a website and publish it with just basic HTML skills, you can make a book with Microsoft Word; I would consider those pretty similar in difficulty.

    In fact, looking at the key question, one thing I wouldn't say digitalization is doing is lowering the barriers to publication. It seems to me that the skills required of an independent publishers double with the introduction of digital issues, as in practice you'll still need those traditional publishing skills while also being responsible for your own digital presence and whatever you publish digitally. As Chris noted in passing up above, one reason for why PDF is so attractive to many publishers is that it allows them to leverage their existing skills in the digital world instead of having to learn it all over again. I can only imagine that this will remain an important quality of the PDF format for a long time to come.
  • Posted By: Eero TuovinenLooking at it from the viewpoint of complete projects, it's not enough to know HTML; you also need CSS, Javascript and probably a bit of server-side programming and databases for a modern website. That's not a small skillset.
    Depending on how deep you want to get, sure. I taught myself HTML in an afternoon, and I've spent ten years perfecting that skill, along with other web technologies. But the time it takes to learn and the time it takes to master really mean two very different things. Even the most basic skills can fill a lifetime of practice for further mastery. As a barrier to entry, though, we have to ask how much skill it takes to get started, not how much skill it takes to become the best or do it professionally.
    Posted By: Eero TuovinenJust like you can make a website and publish it with just basic HTML skills, you can make a book with Microsoft Word; I would consider those pretty similar in difficulty.
    I would agree, those seem of roughly equal difficulty. But my DOC file hasn't yet become a finished product. I still need to print it many, many copies, bind them together somehow, and find some way to distribute them. By comparison, once I have my HTML page online, I've finished.
  • edited December 2009
    CommentAuthorjason

    As a graphic and web designer who does both at times for money: you'll have a much easier time teaching yourself HTML than teaching yourself layout. You can learn HTML in an afternoon. You can learn layout in a few years. Portraying this as merely shifting skill sets seems to miss the more important point: the skill set has become much, much easier and more widely available.



    Ah... but I know InDesign and my HTML skills are minimal. Moving on would mean leaving a skill set I've worked six years to build up. That is just what D+D has done. I realized with 3rd ed that I didn't want to learn all the new niggly stuff so I stepped off the D+D train. Now your point is completely valid to new people coming in to design. They can easily learn the latest alphabet soup. What strikes me though is the question "How long will this be useful?" I've seen the skills I learned 20 years ago become obsolete. Software knowledge being the quickest to age out. The oldest skills I learned in my Dad's art studio are the ones that have remained the most useful. The properties of paper, cardboard, glue, ink. When I think back on Wordstar, Word Perfect, MS Pblisher, Adobe Pagemaker, and InDesign you can see why a person might be a little reluctant to view the next move as the final step.


    CommentAuthorEero Tuovinen

    As Chris noted in passing up above, one reason for why PDF is so attractive to many publishers is that it allows them to leverage their existing skills in the digital world instead of having to learn it all over again. I can only imagine that this will remain an important quality of the PDF format for a long time to come.



    What Eero said! I know that the advancement in machines will eventually force me to upgrade (how long will programs for XP be made? The writing is already on the wall). But until I have a need I feel that my productivity is best served by using the functional machine I have rather than the newest latest. This isn't being a Luddite - it's just recognizing my own cognitive limits. I just can't learn and relearn and relearn and relearn fast enough. I'm forced to skip generations of change until they make it easy enough for a novice to do it.

    Oh! I forgot learning BASIC and Fortan back in the 70's and early 80's...

    Chris Engle
Sign In or Register to comment.