RE: Outsourcing: Was Reasons to Structure
I hope Gillian is correct. We currently have a few good writers in Pune, India, but several atrocious ones as well. I don't think we need to worry about China, but so far, the company I work for doesn't care. Maybe users will convince them that keeping the jobs in the U.S. is a good idea. Sean -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dodd, Frank J Sent: Friday, February 16, 2007 5:33 PM To: framers@lists.frameusers.com Subject: RE: Outsourcing: Was Reasons to Structure So what exactly is the pay range for a technical writer? I ting I kan rite gude and wude licke to chry eet. Seriously. Actually I create work instructions for about 80% of my work time. Frank -Original Message- From: Gillian Flato [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 8:48 AM To: Sean Pollock; [EMAIL PROTECTED]; Randall C. Reed Cc: framers@lists.frameusers.com Subject: Outsourcing: Was Reasons to Structure Out here in Silicon Valley, they tried outsourcing. They found that using Tech Writers whose first language wasn't English was a train wreck. There writing skills were atrocious. After a few years of that, they brought the Tech Writing back to Silicon Valley where they could hire native-speaking educated English-speaking people. So they Tech Writing jobs are coming back to Silicon Valley. So been there, done that, it failed. Additionally, there was a big article in the local paper (San Jose Mercury News) last weekend about how companies have found that outsourcing tech support provided such a drastically poor quality of customer service that the loss in business and customer satisfaction far outweighed any cost benefits, so tech support is coming back to Silicon Valley as well. So again, been there, done that, it failed. -Gillian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Pollock Sent: Thursday, February 15, 2007 8:57 PM To: [EMAIL PROTECTED]; 'Randall C. Reed' Cc: framers@lists.frameusers.com Subject: RE: Reasons to structure: another point of view I've written documentation in the Detroit area for over 20 years and although I know structured Frame and use a custom XML format with Epic Editor/Manager in my present position, I find that most employers here hardly know what FrameMaker is, let alone anything about structured Frame and/or XML/reuse. Time and time again I see jobs that require only a basic knowledge of Ms Office, and I ignore them because I don't think these employers take documentation seriously. Admittedly, Detroit is in bad shape these days, but from my side of the tracks I see few employers who require Frame experience of any kind. My advice is not to worry about attaining Frame guruhood. Instead, diversify into training, biomedical, and other areas that will give you an edge when most tech writing jobs have gone to India. Learn Adobe Flash and Captivate to support those self-paced and instructor-led job opportunities that seem to be floating our way; take Instructional Design courses. It may be a slow boat, but outsourcing IS headed your way; the company I now work for requires that we seek out tech writers in India, even though I'm told that universities there don't offer much in the necessary education. All we can do is hope that those of us with the company for years aren't canned to benefit the next IPO. Sorry for the dire forecast, but the East and West coasts can't be far behind. --Sean Pollock -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, February 15, 2007 12:19 PM To: Randall C. Reed Cc: framers@lists.frameusers.com Subject: RE: Reasons to structure If you work for a company that doesn't accept qualified recommendations for improvement from its staff, you should keep a resume up-to-date. No company can last too long if it doesn't embrace innovation from the lower levels. I think the truth is, actually, that in the majority of cases, tech writers are not qualified to proselytize on structure, because they haven't really learned about it yet. Hence my original point, several postings ago. You have to understand it to present a convincing business case (show them the money, as it were). In the past several years, I've had relatively little difficulty getting acceptance from management for new tools, methods, etc., because I understand the benefits and can clearly enumerate the reasons for doing it. I would like all tech writers to be this way, because I don't want us to be second class in the arena of ideas. When it comes to tools and methods involved with our work, we should be the primary influence on what happens. The key is, though, we need to know what we are talking about first. So I say, get in there and learn. I don't believe for a second that there are only a select few of us that can understand simple tools like structured Frame. You just need to have the desire
Outsourcing: Was Reasons to Structure
I hope Gillian is correct. We currently have a few good writers in Pune, India, but several atrocious ones as well. I don't think we need to worry about China, but so far, the company I work for doesn't care. Maybe users will convince them that keeping the jobs in the U.S. is a good idea. Sean -Original Message- From: framers-bounces+spolloc1=hotmail@lists.frameusers.com [mailto:framers-bounces+spolloc1=hotmail.com at lists.frameusers.com] On Behalf Of Dodd, Frank J Sent: Friday, February 16, 2007 5:33 PM To: framers at lists.frameusers.com Subject: RE: Outsourcing: Was Reasons to Structure So what exactly is the pay range for a technical writer? I ting I kan rite gude and wude licke to chry eet. Seriously. Actually I create work instructions for about 80% of my work time. Frank -Original Message- From: Gillian Flato [mailto:gfl...@nanometrics.com] Sent: Friday, February 16, 2007 8:48 AM To: Sean Pollock; russ at weststreetconsulting.com; Randall C. Reed Cc: framers at lists.frameusers.com Subject: Outsourcing: Was Reasons to Structure Out here in Silicon Valley, they tried outsourcing. They found that using Tech Writers whose first language wasn't English was a train wreck. There writing skills were atrocious. After a few years of that, they brought the Tech Writing back to Silicon Valley where they could hire native-speaking educated English-speaking people. So they Tech Writing jobs are coming back to Silicon Valley. So been there, done that, it failed. Additionally, there was a big article in the local paper (San Jose Mercury News) last weekend about how companies have found that outsourcing tech support provided such a drastically poor quality of customer service that the loss in business and customer satisfaction far outweighed any cost benefits, so tech support is coming back to Silicon Valley as well. So again, been there, done that, it failed. -Gillian -Original Message- From: framers-bounces+gflato=nanometrics@lists.frameusers.com [mailto:framers-bounces+gflato=nanometrics.com at lists.frameusers.com] On Behalf Of Sean Pollock Sent: Thursday, February 15, 2007 8:57 PM To: russ at weststreetconsulting.com; 'Randall C. Reed' Cc: framers at lists.frameusers.com Subject: RE: Reasons to structure: another point of view I've written documentation in the Detroit area for over 20 years and although I know structured Frame and use a custom XML format with Epic Editor/Manager in my present position, I find that most employers here hardly know what FrameMaker is, let alone anything about structured Frame and/or XML/reuse. Time and time again I see jobs that require only a basic knowledge of Ms Office, and I ignore them because I don't think these employers take documentation seriously. Admittedly, Detroit is in bad shape these days, but from my side of the tracks I see few employers who require Frame experience of any kind. My advice is not to worry about attaining Frame guruhood. Instead, diversify into training, biomedical, and other areas that will give you an edge when most tech writing jobs have gone to India. Learn Adobe Flash and Captivate to support those self-paced and instructor-led job opportunities that seem to be floating our way; take Instructional Design courses. It may be a slow boat, but outsourcing IS headed your way; the company I now work for requires that we seek out tech writers in India, even though I'm told that universities there don't offer much in the necessary education. All we can do is hope that those of us with the company for years aren't canned to benefit the next IPO. Sorry for the dire forecast, but the East and West coasts can't be far behind. --Sean Pollock -Original Message- From: framers-bounces+spolloc1=hotmail@lists.frameusers.com [mailto:framers-bounces+spolloc1=hotmail.com at lists.frameusers.com] On Behalf Of russ at weststreetconsulting.com Sent: Thursday, February 15, 2007 12:19 PM To: Randall C. Reed Cc: framers at lists.frameusers.com Subject: RE: Reasons to structure If you work for a company that doesn't accept qualified recommendations for improvement from its staff, you should keep a resume up-to-date. No company can last too long if it doesn't embrace innovation from the lower levels. I think the truth is, actually, that in the majority of cases, tech writers are not qualified to proselytize on structure, because they haven't really learned about it yet. Hence my original point, several postings ago. You have to understand it to present a convincing business case (show them the money, as it were). In the past several years, I've had relatively little difficulty getting acceptance from management for new tools, methods, etc., because I understand the benefits and can clearly enumerate the reasons for doing it. I would like all tech writers to be this way, because I don't want us to be second class in the arena of ideas. When it comes to tools and methods involved with our work, we
Re: Reasons to Structure
To be very simplistic, we already do structure, though we do it in a sloppy, and rules bereft manner. Normally we use visual structuring of documents. In other words, formatting. Applying very strict rules to formatting brings us closer to structured data. Until one day we transfer those rules away from formatting and concentrate totally upon the relationship of the information to the information around it. Scott ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Reasons to Structure
Jeremy H. Griffith wrote: > Isn't that a tad harsh, Russ? My point, which you appear to have > missed, is that (as Richard said) semantic markup is good, *and* > that you can do it in unstructured Frame. Do you deny this fact? Wholeheartedly. Semantic markup only exists if it is expressed in a way that a computer can make use of it - structure exists expressly for that purpose. Considering a document to be semantically rich when the semantics cannot be easily exposed is a bit like writing the world's greatest novel in a language that only you understand. I understand how the focus on this group is about how structure impacts on the authors and editors of data, but in fact structure wasn't created to make the lives of those people easier or more difficult. Structure was created to make information more useful, and people who create that information are simply along for the ride. That's why I advocate the structural design being done by an information architect, because in the big picture it matters not a whit how the imposition of structure impacts those people, despite the fact that it may make for interesting discussion. > I also said that for small groups, "the setup costs (time and > consultants) are likely to exceed the benefits". I'll stand by > that assessment, based on using Frame in both its unstructured > *and* structured (formerly known as "FrameBuilder") forms over > many, many years, originally on a Sun 2... I didn't say there > are *no* benefits, just that the costs may be greater. Do you > assert that the costs are always insignificant, then? The costs and benefits are at least partially unrelated to tasks of creating and editing data. The cost and the learning curve can look high, but if it's a corporate decision driven by IT needs, chances are those costs have been justified in another part of the organisation. I do agree that if people are doing structure for the sake of it, or because they think that it will make their editing easier, they may be barking up the wrong tree. If you don't need structure, the cost of it may be prohibitive, though that just sounds like a truism. > Assuming, that is, that you *have* the time. Many of our > colleagues, having survived downsizing from ten writers to > two with no decrease of workload, do not. And if you do, > is that time better spent on learning nifty new tools, or > on improving the docs you're paid to write? One size does > *not* fit all. If you have a genuine *business* case for > going to structured Frame (or if you are a hacker at heart, > like you and I), go for it. ;-) I agree with that. I'd add that if you can get your employer to pay for you to learn structure, then take advantage of it. In years to come, structure will become more prevalent - it has to as the semantic web emerges. > The Web? You don't consider HTML an example of structured > content, do you? It qualifies in only the most technical > sense... and most pages violate even its simple DTDs grossly. > Or maybe it's not recent enough for you? Yep, HTML was developed as a profile of SGML. Tag omission was perfectly valid in SGML, as long as the processor could infer the element boundaries. The fact that the browser makers were in a race to see who could accept the crappiest data isn't a reflection on HTML, it's a reflection on the browser makers. Besides, with XSLT being applied to XML to create HTML (and just the fact that people are getting used to XML) I suspect that the quality of HTML data on the web has improved over the past few years. > However, more to the point, unlike the typewriter salesman > I make *nothing* when people stay with unstructured Frame. > You, OTOH, make your living from people who go structured. > Perhaps it's the *computer* salesman you need to watch? ;-) My company hasn't done a structured FrameMaker application for a good few years, but I still get lumped with the odd support call. I certainly wouldn't say that I make money out of structured FrameMaker, though virtually all of our revenue comes from structured data. -- Regards, Marcus Carr email: mcarr at allette.com.au ___ Allette Systems (Australia) www:http://www.allette.com.au ___ "Everything should be made as simple as possible, but not simpler." - Einstein
Outsourcing: Was Reasons to Structure
Out here in Silicon Valley, they tried outsourcing. They found that using Tech Writers whose first language wasn't English was a train wreck. There writing skills were atrocious. After a few years of that, they brought the Tech Writing back to Silicon Valley where they could hire native-speaking educated English-speaking people. So they Tech Writing jobs are coming back to Silicon Valley. So been there, done that, it failed. Additionally, there was a big article in the local paper (San Jose Mercury News) last weekend about how companies have found that outsourcing tech support provided such a drastically poor quality of customer service that the loss in business and customer satisfaction far outweighed any cost benefits, so tech support is coming back to Silicon Valley as well. So again, been there, done that, it failed. -Gillian -Original Message- From: framers-bounces+gflato=nanometrics@lists.frameusers.com [mailto:framers-bounces+gflato=nanometrics.com at lists.frameusers.com] On Behalf Of Sean Pollock Sent: Thursday, February 15, 2007 8:57 PM To: russ at weststreetconsulting.com; 'Randall C. Reed' Cc: framers at lists.frameusers.com Subject: RE: Reasons to structure: another point of view I've written documentation in the Detroit area for over 20 years and although I know structured Frame and use a custom XML format with Epic Editor/Manager in my present position, I find that most employers here hardly know what FrameMaker is, let alone anything about structured Frame and/or XML/reuse. Time and time again I see jobs that require only a basic knowledge of Ms Office, and I ignore them because I don't think these employers take documentation seriously. Admittedly, Detroit is in bad shape these days, but from my side of the tracks I see few employers who require Frame experience of any kind. My advice is not to worry about attaining Frame guruhood. Instead, diversify into training, biomedical, and other areas that will give you an edge when most tech writing jobs have gone to India. Learn Adobe Flash and Captivate to support those self-paced and instructor-led job opportunities that seem to be floating our way; take Instructional Design courses. It may be a slow boat, but outsourcing IS headed your way; the company I now work for requires that we seek out tech writers in India, even though I'm told that universities there don't offer much in the necessary education. All we can do is hope that those of us with the company for years aren't canned to benefit the next IPO. Sorry for the dire forecast, but the East and West coasts can't be far behind. --Sean Pollock -Original Message- From: framers-bounces+spolloc1=hotmail@lists.frameusers.com [mailto:framers-bounces+spolloc1=hotmail.com at lists.frameusers.com] On Behalf Of russ at weststreetconsulting.com Sent: Thursday, February 15, 2007 12:19 PM To: Randall C. Reed Cc: framers at lists.frameusers.com Subject: RE: Reasons to structure If you work for a company that doesn't accept qualified recommendations for improvement from its staff, you should keep a resume up-to-date. No company can last too long if it doesn't embrace innovation from the lower levels. I think the truth is, actually, that in the majority of cases, tech writers are not qualified to proselytize on structure, because they haven't really learned about it yet. Hence my original point, several postings ago. You have to understand it to present a convincing business case (show them the money, as it were). In the past several years, I've had relatively little difficulty getting acceptance from management for new tools, methods, etc., because I understand the benefits and can clearly enumerate the reasons for doing it. I would like all tech writers to be this way, because I don't want us to be second class in the arena of ideas. When it comes to tools and methods involved with our work, we should be the primary influence on what happens. The key is, though, we need to know what we are talking about first. So I say, get in there and learn. I don't believe for a second that there are only a select few of us that can understand simple tools like structured Frame. You just need to have the desire and understanding of how important it is. Original Message Subject: RE: Reasons to structure From: "Randall C. Reed" <randall.r...@forceprotection.net> Date: Thu, February 15, 2007 9:11 am To: , Russ West says: "It is so important for any tech writer to learn about structured content..." The funny thing is, in the majority of cases, we are not in a position to proselytize for or against structured documentation. That's usually decided several pay grades higher by contract deliverable or other edict. We rarely. If ever, get to choose or even recommend! But a TW who wishes to remain employable should be able to respond to structured or unstructured requirements by being able to work in both. The general trend
Outsourcing: Was Reasons to Structure
So what exactly is the pay range for a technical writer? I ting I kan rite gude and wude licke to chry eet. Seriously. Actually I create work instructions for about 80% of my work time. Frank -Original Message- From: Gillian Flato [mailto:gfl...@nanometrics.com] Sent: Friday, February 16, 2007 8:48 AM To: Sean Pollock; russ at weststreetconsulting.com; Randall C. Reed Cc: framers at lists.frameusers.com Subject: Outsourcing: Was Reasons to Structure Out here in Silicon Valley, they tried outsourcing. They found that using Tech Writers whose first language wasn't English was a train wreck. There writing skills were atrocious. After a few years of that, they brought the Tech Writing back to Silicon Valley where they could hire native-speaking educated English-speaking people. So they Tech Writing jobs are coming back to Silicon Valley. So been there, done that, it failed. Additionally, there was a big article in the local paper (San Jose Mercury News) last weekend about how companies have found that outsourcing tech support provided such a drastically poor quality of customer service that the loss in business and customer satisfaction far outweighed any cost benefits, so tech support is coming back to Silicon Valley as well. So again, been there, done that, it failed. -Gillian -Original Message- From: framers-bounces+gflato=nanometrics@lists.frameusers.com [mailto:framers-bounces+gflato=nanometrics.com at lists.frameusers.com] On Behalf Of Sean Pollock Sent: Thursday, February 15, 2007 8:57 PM To: russ at weststreetconsulting.com; 'Randall C. Reed' Cc: framers at lists.frameusers.com Subject: RE: Reasons to structure: another point of view I've written documentation in the Detroit area for over 20 years and although I know structured Frame and use a custom XML format with Epic Editor/Manager in my present position, I find that most employers here hardly know what FrameMaker is, let alone anything about structured Frame and/or XML/reuse. Time and time again I see jobs that require only a basic knowledge of Ms Office, and I ignore them because I don't think these employers take documentation seriously. Admittedly, Detroit is in bad shape these days, but from my side of the tracks I see few employers who require Frame experience of any kind. My advice is not to worry about attaining Frame guruhood. Instead, diversify into training, biomedical, and other areas that will give you an edge when most tech writing jobs have gone to India. Learn Adobe Flash and Captivate to support those self-paced and instructor-led job opportunities that seem to be floating our way; take Instructional Design courses. It may be a slow boat, but outsourcing IS headed your way; the company I now work for requires that we seek out tech writers in India, even though I'm told that universities there don't offer much in the necessary education. All we can do is hope that those of us with the company for years aren't canned to benefit the next IPO. Sorry for the dire forecast, but the East and West coasts can't be far behind. --Sean Pollock -Original Message- From: framers-bounces+spolloc1=hotmail@lists.frameusers.com [mailto:framers-bounces+spolloc1=hotmail.com at lists.frameusers.com] On Behalf Of russ at weststreetconsulting.com Sent: Thursday, February 15, 2007 12:19 PM To: Randall C. Reed Cc: framers at lists.frameusers.com Subject: RE: Reasons to structure If you work for a company that doesn't accept qualified recommendations for improvement from its staff, you should keep a resume up-to-date. No company can last too long if it doesn't embrace innovation from the lower levels. I think the truth is, actually, that in the majority of cases, tech writers are not qualified to proselytize on structure, because they haven't really learned about it yet. Hence my original point, several postings ago. You have to understand it to present a convincing business case (show them the money, as it were). In the past several years, I've had relatively little difficulty getting acceptance from management for new tools, methods, etc., because I understand the benefits and can clearly enumerate the reasons for doing it. I would like all tech writers to be this way, because I don't want us to be second class in the arena of ideas. When it comes to tools and methods involved with our work, we should be the primary influence on what happens. The key is, though, we need to know what we are talking about first. So I say, get in there and learn. I don't believe for a second that there are only a select few of us that can understand simple tools like structured Frame. You just need to have the desire and understanding of how important it is. Original Message Subject: RE: Reasons to structure From: "Randall C. Reed" <randall.r...@forceprotection.net> Date: Thu, February 15, 2007 9:11 am To: , Russ West says: "It is so important for any tech writer to l
Reasons to Structure
To be very simplistic, we already do structure, though we do it in a sloppy, and rules bereft manner. Normally we use visual structuring of documents. In other words, formatting. Applying very strict rules to formatting brings us closer to structured data. Until one day we transfer those rules away from formatting and concentrate totally upon the relationship of the information to the information around it. Scott
RE: Reasons to structure
If you work in the tech industry and don't have time to learn, your fate is sealed. I know what you are saying, but you are presuming that learning how to use a technology is more important than learning whether or not that technology is cost-effective to me in my current situation. On top of that, at the moment and to a lot of people, structured FrameMaker talks the talk but -heavens to betsy- the walk looks like a complicated one. When the walk is a little easier, I'll start to learn the steps. Just as I did with HTML, then CSS. There is a brewing thought in here about Tipping Points but time marches on.. So, that's what I have learned about structured FrameMaker, but then I tend to let the early adopters do all the work and then swoop in later on. ;-) G -Original Message- Jeremy, I don't think that is harsh at all. What I think is harsh is the constant discouragement from learning and professional development from certain members of this list. It is so important for any tech writer to learn about structured content, and I do not think I am any smarter than anyone else just because I have expertise in structure. The only difference with me is that I just spent the last five years being interested in it, and I would like others to be interested in it as well. And that excuse about not having time is really quite worn out. If you work in the tech industry and don't have time to learn, your fate is sealed. And by the way, HTML is a perfect example of fully structured content, and the web is a good example of the miracles that are possible with it. Thanks for bringing that up. This email (and any attachments) is private and confidential, and is intended solely for the addressee. If you have received this communication in error please remove it and inform us via telephone or email. Although we take all possible steps to ensure mail and attachments are free from malicious content, malware and viruses, we cannot accept any responsibility whatsoever for any changes to content outwith our administrative bounds. The views represented within this mail are solely the view of the author and do not reflect the views of the organisation as a whole. Graham Technology plc Registered in Scotland company no. SC143434 Registered Office India of Inchinnan, Renfrewshire, Scotland PA4 9LH http://www.grahamtechnology.com ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Reasons to structure
You may want to look over, and play with, the FM DITA plug in. It's a structured tool, obviously, but seems to be a rationally usable tool rather than an entire philosophy. Art On 2/15/07, Gordon McLean [EMAIL PROTECTED] wrote: If you work in the tech industry and don't have time to learn, your fate is sealed. I know what you are saying, but you are presuming that learning how to use a technology is more important than learning whether or not that technology is cost-effective to me in my current situation. On top of that, at the moment and to a lot of people, structured FrameMaker talks the talk but -heavens to betsy- the walk looks like a complicated one. When the walk is a little easier, I'll start to learn the steps. Just as I did with HTML, then CSS. There is a brewing thought in here about Tipping Points but time marches on.. So, that's what I have learned about structured FrameMaker, but then I tend to let the early adopters do all the work and then swoop in later on. ;-) G -Original Message- Jeremy, I don't think that is harsh at all. What I think is harsh is the constant discouragement from learning and professional development from certain members of this list. It is so important for any tech writer to learn about structured content, and I do not think I am any smarter than anyone else just because I have expertise in structure. The only difference with me is that I just spent the last five years being interested in it, and I would like others to be interested in it as well. And that excuse about not having time is really quite worn out. If you work in the tech industry and don't have time to learn, your fate is sealed. And by the way, HTML is a perfect example of fully structured content, and the web is a good example of the miracles that are possible with it. Thanks for bringing that up. -- Art Campbell [EMAIL PROTECTED] ... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl. -- Richard Thompson No disclaimers apply. DoD 358 ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Reasons To Structure
One more reason, at least for my team, and I did not see this in the thread (not directly said, anyway) is that we have a totally diff publishing model here at FedEx. Our model is stood on its head, so to speak. By that, I mean that our small group of writers function as a 'service bureau'. We are the only authors with Frame. However, our large body of 'authors', the SMEs, of course, author in Word. The, we must copy paste their content into Frame, which amounts to a big waste of time _ theirs in fooling with all the formatting in Word, and ours by not being able to use their work, directly. So, we are trying to solve that problem by going to Structured Frame and DITA, and then use the XMetal collaboration tool, XMAX, to provide a web-based interface in which they can author xml in a 'word-like' environment (we call it 'Bait Switch'). Finally, we will use the Documentum CMS to manage it all (workflow and configuration management). I'll let you all know how it shakes out. Steve Gillespie, PMP Sr Information Development Analyst FedEx Express Memphis, TN 38125 901.434.9982 ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Reasons to Structure
All the reasons to use structured FrameMaker that people have submitted focus on the net benefits, which is probably the main reason why you would do this. However, here's a complementary take on it. As a lone writer, I did all the work to write an EDD and convert my unstructured doc to structured format. I continue to update the EDD to this day. Although occasionally frustrating, I got a great sense of accomplishment from the initial work, and continue to enjoy coming up with ways to improve how I manage my documents. If you enjoy the tech in tech writer and like working on the tools that make your day-to-day job easier, it's a lot of fun. (Going structured also lets you take advantage of some of the great tools that Russ Ward has written.) Fred -- Fred Wersan Senior Technical Writer MAK Technologies 68 Moulton St. Cambridge, MA 02138 617-876-8085 x 124 ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: [BULK] RE: Reasons to structure
Russ West says: It is so important for any tech writer to learn about structured content... The funny thing is, in the majority of cases, we are not in a position to proselytize for or against structured documentation. That's usually decided several pay grades higher by contract deliverable or other edict. We rarely. If ever, get to choose or even recommend! But a TW who wishes to remain employable should be able to respond to structured or unstructured requirements by being able to work in both. The general trend in technical publishing, I predict (duh!), will require more automation, more reusability, more interchangeability of data, not less. If I had to bet on a winner in that horse race, my money would be on more structured documentation, not less, in our collective future. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] s.com] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, February 15, 2007 8:09 AM To: framers@lists.frameusers.com Subject: [BULK] RE: Reasons to structure Importance: Low Jeremy, I don't think that is harsh at all. What I think is harsh is the constant discouragement from learning and professional development from certain members of this list. It is so important for any tech writer to learn about structured content, and I do not think I am any smarter than anyone else just because I have expertise in structure. The only difference with me is that I just spent the last five years being interested in it, and I would like others to be interested in it as well. And that excuse about not having time is really quite worn out. If you work in the tech industry and don't have time to learn, your fate is sealed. And by the way, HTML is a perfect example of fully structured content, and the web is a good example of the miracles that are possible with it. Thanks for bringing that up. Message: 29 Date: Wed, 14 Feb 2007 17:46:00 -0800 From: Jeremy H. Griffith [EMAIL PROTECTED] Subject: Re: Reasons to Structure To: framers@lists.frameusers.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 On Wed, 14 Feb 2007 04:56:49 -0700, [EMAIL PROTECTED] wrote: Jeremy Griffith wrote [referring to semantic markup]: You can do the same with paragraph formats, too. But you can do all that in UNstructured docs just as easily as in structured. Maybe *more* easily, when you factor in the time to set up your structure, and to modify it when you make changes, which is major. I've only been able to identify one situation in which structured Frame can do this better than unstructured, and that's when you'd want nested element tags within a paragraph, since you cam't nest character formats. (There are easy workarounds for creating the equivalent of nested paragraph formats, such as using start/end formats and/or markers.) OTOH, I have yet to see a non-hypothetical case where such nested char formats were really needed... Structured Frame is designed for large pubs groups where standard document designs are required, perhaps for ISO 9000, perhaps for other corporate policy reasons. For smaller groups, and especially for lone writers, the setup costs (time and consultants) are likely to exceed the benefits, much like a CMS (Content Management System) can. There are excellent consultants around, many on this list, for whom it is a breeze. If you decide to go this way, hire one. It will prevent much anguish and hair loss. This is misinformation, on nearly all counts. Isn't that a tad harsh, Russ? My point, which you appear to have missed, is that (as Richard said) semantic markup is good, *and* that you can do it in unstructured Frame. Do you deny this fact? I also said that for small groups, the setup costs (time and consultants) are likely to exceed the benefits. I'll stand by that assessment, based on using Frame in both its unstructured *and* structured (formerly known as FrameBuilder) forms over many, many years, originally on a Sun 2... I didn't say there are *no* benefits, just that the costs may be greater. Do you assert that the costs are always insignificant, then? I am a lone writer who is completely dependent on structured Frame. Without it, I would need at least twice the manpower to handle the busywork that it does. Furthermore, I adhere to no industry standard and make changes to my structured template frequently. All well and good... but what *else* are you? An expert in structure, perhaps? How long have you worked with structure? As I said, There are excellent consultants around, many on this list, for whom it is a breeze. You are one of the four or five I'd think of first... Here's the first line on your home page: Welcome to West Street Consulting, your home for structured FrameMaker(r) plugins and other utilities. I've also written plugins that work with structured Frame (Mif2Go does, just fine), but I hardly consider myself a representative Frame user... nor would I assume that everyone would
Re: Reasons to Structure
Matt's question is, to some degree, academic and as a result list members have made many valid points, some totally at odds with others. (Isn't that the point of academia? :) In practice, the questions are: What will structure do for *my* problems and what will it cost to implement? I said the following recently in response to a similar question about XML over on techwr-l: For a long time my XML philosophy was, If you need XML, you're already there. I've come off that belief as tools, best practices, and the like developed and evolved. That said, my current XML philosophy is Don't deploy XML unless you have a clear set of goals and objectives and have a good understanding of the costs (effort, software, hardware, etc.) required to achieve those goals. In other words, XML for the sake of XML is a time and money pit. (My old philosophy was so much more catchy! ;( Find/replace XML with structure and you have my opinion on structure (less the catchy phrases). You better know why you're structuring your content and have a deep understanding of the obvious and hidden costs. Then it's just math ... is there ROI? -- Paul Nagai ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Reasons to structure
If you work for a company that doesn't accept qualified recommendations for improvement from its staff, you should keep a resume up-to-date. No company can last too long if it doesn't embrace innovation from the lower levels. I think the truth is, actually, that in the majority of cases, tech writers are not qualified to proselytize on structure, because they haven't really learned about it yet. Hence my original point, several postings ago. You have to understand it to present a convincing business case (show them the money, as it were). In the past several years, I've had relatively little difficulty getting acceptance from management for new tools, methods, etc., because I understand the benefits and can clearly enumerate the reasons for doing it. I would like all tech writers to be this way, because I don't want us to be second class in the arena of ideas. When it comes to tools and methods involved with our work, we should be the primary influence on what happens. The key is, though, we need to know what we are talking about first. So I say, get in there and learn. I don't believe for a second that there are only a select few of us that can understand simple tools like structured Frame. You just need to have the desire and understanding of how important it is. Original Message Subject: RE: Reasons to structure From: Randall C. Reed [EMAIL PROTECTED] Date: Thu, February 15, 2007 9:11 am To: [EMAIL PROTECTED],framers@lists.frameusers.com Russ West says: It is so important for any tech writer to learn about structured content... The funny thing is, in the majority of cases, we are not in a position to proselytize for or against structured documentation. That's usually decided several pay grades higher by contract deliverable or other edict. We rarely. If ever, get to choose or even recommend! But a TW who wishes to remain employable should be able to respond to structured or unstructured requirements by being able to work in both. The general trend in technical publishing, I predict (duh!), will require more automation, more reusability, more interchangeability of data, not less. If I had to bet on a winner in that horse race, my money would be on more structured documentation, not less, in our collective future. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Reasons to structure
I'm on the FM-DITA mailing list Art, and was invovled about a year or two ago when it was just starting out. I still keep on top of things, but in my last place we switched to AuthorIT as it meet our needs. My current position already has a structured FrameMaker setup, so I've missed the chance to 'learn it hands on'. I'm not against structured FrameMaker, but, and I said this in the early DITA days as well, it's a bit daunting for some people and would benefit from a simple way to 'get into it'. I agree that DITA is probably that very way. G -Original Message- You may want to look over, and play with, the FM DITA plug in. It's a structured tool, obviously, but seems to be a rationally usable tool rather than an entire philosophy. Art On 2/15/07, Gordon McLean [EMAIL PROTECTED] wrote: If you work in the tech industry and don't have time to learn, your fate is sealed. I know what you are saying, but you are presuming that learning how to use a technology is more important than learning whether or not that technology is cost-effective to me in my current situation. On top of that, at the moment and to a lot of people, structured FrameMaker talks the talk but -heavens to betsy- the walk looks like a complicated one. When the walk is a little easier, I'll start to learn the steps. Just as I did with HTML, then CSS. There is a brewing thought in here about Tipping Points but time marches on.. This email (and any attachments) is private and confidential, and is intended solely for the addressee. If you have received this communication in error please remove it and inform us via telephone or email. Although we take all possible steps to ensure mail and attachments are free from malicious content, malware and viruses, we cannot accept any responsibility whatsoever for any changes to content outwith our administrative bounds. The views represented within this mail are solely the view of the author and do not reflect the views of the organisation as a whole. Graham Technology plc Registered in Scotland company no. SC143434 Registered Office India of Inchinnan, Renfrewshire, Scotland PA4 9LH http://www.grahamtechnology.com ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Reasons to Structure
Jeremy H. Griffith wrote: Isn't that a tad harsh, Russ? My point, which you appear to have missed, is that (as Richard said) semantic markup is good, *and* that you can do it in unstructured Frame. Do you deny this fact? Wholeheartedly. Semantic markup only exists if it is expressed in a way that a computer can make use of it - structure exists expressly for that purpose. Considering a document to be semantically rich when the semantics cannot be easily exposed is a bit like writing the world's greatest novel in a language that only you understand. I understand how the focus on this group is about how structure impacts on the authors and editors of data, but in fact structure wasn't created to make the lives of those people easier or more difficult. Structure was created to make information more useful, and people who create that information are simply along for the ride. That's why I advocate the structural design being done by an information architect, because in the big picture it matters not a whit how the imposition of structure impacts those people, despite the fact that it may make for interesting discussion. I also said that for small groups, the setup costs (time and consultants) are likely to exceed the benefits. I'll stand by that assessment, based on using Frame in both its unstructured *and* structured (formerly known as FrameBuilder) forms over many, many years, originally on a Sun 2... I didn't say there are *no* benefits, just that the costs may be greater. Do you assert that the costs are always insignificant, then? The costs and benefits are at least partially unrelated to tasks of creating and editing data. The cost and the learning curve can look high, but if it's a corporate decision driven by IT needs, chances are those costs have been justified in another part of the organisation. I do agree that if people are doing structure for the sake of it, or because they think that it will make their editing easier, they may be barking up the wrong tree. If you don't need structure, the cost of it may be prohibitive, though that just sounds like a truism. Assuming, that is, that you *have* the time. Many of our colleagues, having survived downsizing from ten writers to two with no decrease of workload, do not. And if you do, is that time better spent on learning nifty new tools, or on improving the docs you're paid to write? One size does *not* fit all. If you have a genuine *business* case for going to structured Frame (or if you are a hacker at heart, like you and I), go for it. ;-) I agree with that. I'd add that if you can get your employer to pay for you to learn structure, then take advantage of it. In years to come, structure will become more prevalent - it has to as the semantic web emerges. The Web? You don't consider HTML an example of structured content, do you? It qualifies in only the most technical sense... and most pages violate even its simple DTDs grossly. Or maybe it's not recent enough for you? Yep, HTML was developed as a profile of SGML. Tag omission was perfectly valid in SGML, as long as the processor could infer the element boundaries. The fact that the browser makers were in a race to see who could accept the crappiest data isn't a reflection on HTML, it's a reflection on the browser makers. Besides, with XSLT being applied to XML to create HTML (and just the fact that people are getting used to XML) I suspect that the quality of HTML data on the web has improved over the past few years. However, more to the point, unlike the typewriter salesman I make *nothing* when people stay with unstructured Frame. You, OTOH, make your living from people who go structured. Perhaps it's the *computer* salesman you need to watch? ;-) My company hasn't done a structured FrameMaker application for a good few years, but I still get lumped with the odd support call. I certainly wouldn't say that I make money out of structured FrameMaker, though virtually all of our revenue comes from structured data. -- Regards, Marcus Carr email: [EMAIL PROTECTED] ___ Allette Systems (Australia) www:http://www.allette.com.au ___ Everything should be made as simple as possible, but not simpler. - Einstein ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Reasons to structure: another point of view
I've written documentation in the Detroit area for over 20 years and although I know structured Frame and use a custom XML format with Epic Editor/Manager in my present position, I find that most employers here hardly know what FrameMaker is, let alone anything about structured Frame and/or XML/reuse. Time and time again I see jobs that require only a basic knowledge of Ms Office, and I ignore them because I don't think these employers take documentation seriously. Admittedly, Detroit is in bad shape these days, but from my side of the tracks I see few employers who require Frame experience of any kind. My advice is not to worry about attaining Frame guruhood. Instead, diversify into training, biomedical, and other areas that will give you an edge when most tech writing jobs have gone to India. Learn Adobe Flash and Captivate to support those self-paced and instructor-led job opportunities that seem to be floating our way; take Instructional Design courses. It may be a slow boat, but outsourcing IS headed your way; the company I now work for requires that we seek out tech writers in India, even though I'm told that universities there don't offer much in the necessary education. All we can do is hope that those of us with the company for years aren't canned to benefit the next IPO. Sorry for the dire forecast, but the East and West coasts can't be far behind. --Sean Pollock -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, February 15, 2007 12:19 PM To: Randall C. Reed Cc: framers@lists.frameusers.com Subject: RE: Reasons to structure If you work for a company that doesn't accept qualified recommendations for improvement from its staff, you should keep a resume up-to-date. No company can last too long if it doesn't embrace innovation from the lower levels. I think the truth is, actually, that in the majority of cases, tech writers are not qualified to proselytize on structure, because they haven't really learned about it yet. Hence my original point, several postings ago. You have to understand it to present a convincing business case (show them the money, as it were). In the past several years, I've had relatively little difficulty getting acceptance from management for new tools, methods, etc., because I understand the benefits and can clearly enumerate the reasons for doing it. I would like all tech writers to be this way, because I don't want us to be second class in the arena of ideas. When it comes to tools and methods involved with our work, we should be the primary influence on what happens. The key is, though, we need to know what we are talking about first. So I say, get in there and learn. I don't believe for a second that there are only a select few of us that can understand simple tools like structured Frame. You just need to have the desire and understanding of how important it is. Original Message Subject: RE: Reasons to structure From: Randall C. Reed [EMAIL PROTECTED] Date: Thu, February 15, 2007 9:11 am To: [EMAIL PROTECTED],framers@lists.frameusers.com Russ West says: It is so important for any tech writer to learn about structured content... The funny thing is, in the majority of cases, we are not in a position to proselytize for or against structured documentation. That's usually decided several pay grades higher by contract deliverable or other edict. We rarely. If ever, get to choose or even recommend! But a TW who wishes to remain employable should be able to respond to structured or unstructured requirements by being able to work in both. The general trend in technical publishing, I predict (duh!), will require more automation, more reusability, more interchangeability of data, not less. If I had to bet on a winner in that horse race, my money would be on more structured documentation, not less, in our collective future. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/spolloc1%40hotmail.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Reasons to structure
Jeremy, I don't think that is harsh at all. What I think is harsh is the constant discouragement from learning and professional development from certain members of this list. It is so important for any tech writer to learn about structured content, and I do not think I am any smarter than anyone else just because I have expertise in structure. The only difference with me is that I just spent the last five years being interested in it, and I would like others to be interested in it as well. And that excuse about "not having time" is really quite worn out. If you work in the tech industry and don't have time to learn, your fate is sealed. And by the way, HTML is a perfect example of fully structured content, and the web is a good example of the miracles that are possible with it. Thanks for bringing that up. Message: 29 Date: Wed, 14 Feb 2007 17:46:00 -0800 From: "Jeremy H. Griffith" <jer...@omsys.com> Subject: Re: Reasons to Structure To: framers at lists.frameusers.com Message-ID: <2ib7t2p94cn4i7lv0j116s5svf7bhpld1u at 4ax.com> Content-Type: text/plain; charset=ISO-8859-1 On Wed, 14 Feb 2007 04:56:49 -0700, russ at weststreetconsulting.com wrote: >Jeremy Griffith wrote [referring to semantic markup]: > >>You can do the same with paragraph formats, too. But you can >>do all that in UNstructured docs just as easily as in structured. >>Maybe *more* easily, when you factor in the time to set up your >>structure, and to modify it when you make changes, which is major. >> >>I've only been able to identify one situation in which structured >>Frame can do this better than unstructured, and that's when you'd >>want nested element tags within a paragraph, since you cam't nest >>character formats. (There are easy workarounds for creating the >>equivalent of nested paragraph formats, such as using start/end >>formats and/or markers.) OTOH, I have yet to see a non-hypothetical >>case where such nested char formats were really needed... >> >>Structured Frame is designed for large pubs groups where standard >>document designs are required, perhaps for ISO 9000, perhaps for >>other corporate policy reasons. For smaller groups, and especially >>for lone writers, the setup costs (time and consultants) are likely >>to exceed the benefits, much like a CMS (Content Management System) >>can. There are excellent consultants around, many on this list, >>for whom it is a breeze. If you decide to go this way, hire one. >>It will prevent much anguish and hair loss. >This is misinformation, on nearly all counts. Isn't that a tad harsh, Russ? My point, which you appear to have missed, is that (as Richard said) semantic markup is good, *and* that you can do it in unstructured Frame. Do you deny this fact? I also said that for small groups, "the setup costs (time and consultants) are likely to exceed the benefits". I'll stand by that assessment, based on using Frame in both its unstructured *and* structured (formerly known as "FrameBuilder") forms over many, many years, originally on a Sun 2... I didn't say there are *no* benefits, just that the costs may be greater. Do you assert that the costs are always insignificant, then? >I am a lone writer who is completely dependent on structured Frame. >Without it, I would need at least twice the manpower to handle the >busywork that it does. Furthermore, I adhere to no industry standard >and make changes to my structured template frequently. All well and good... but what *else* are you? An expert in structure, perhaps? How long have you worked with structure? As I said, "There are excellent consultants around, many on this list, for whom it is a breeze." You are one of the four or five I'd think of first... Here's the first line on your home page: "Welcome to West Street Consulting, your home for structured FrameMaker? plugins and other utilities." I've also written plugins that work with structured Frame (Mif2Go does, just fine), but I hardly consider myself a representative Frame user... nor would I assume that everyone would have as easy a time as I do. Do you say it's easy for everyone? >Granted, the setup costs for me are minimal now, because I >have the skill set. My point exactly. That's why I said "hire a consultant". Do you think consultants are unnecessary? >But that is the whole point of these occasional rants... you >just have to get in there and learn, because that's when it >becomes a breeze. Assuming, that is, that you *have* the time. Many of our colleagues, having survived downsizing from ten writers to two with no decrease of workload, do not. And if you do, is that time better spent on learning nifty new tools, or on improving the docs you're paid to write
Reasons to structure
"If you work in the tech industry and don't have time to learn, your fate is sealed." I know what you are saying, but you are presuming that learning how to use a technology is more important than learning whether or not that technology is cost-effective to me in my current situation. On top of that, at the moment and to a lot of people, structured FrameMaker talks the talk but -heavens to betsy- the walk looks like a complicated one. When the walk is a little easier, I'll start to learn the steps. Just as I did with HTML, then CSS. There is a brewing thought in here about Tipping Points but time marches on.. So, that's what I have learned about structured FrameMaker, but then I tend to let the early adopters do all the work and then swoop in later on. ;-) G -Original Message- Jeremy, I don't think that is harsh at all. What I think is harsh is the constant discouragement from learning and professional development from certain members of this list. It is so important for any tech writer to learn about structured content, and I do not think I am any smarter than anyone else just because I have expertise in structure. The only difference with me is that I just spent the last five years being interested in it, and I would like others to be interested in it as well. And that excuse about "not having time" is really quite worn out. If you work in the tech industry and don't have time to learn, your fate is sealed. And by the way, HTML is a perfect example of fully structured content, and the web is a good example of the miracles that are possible with it. Thanks for bringing that up. This email (and any attachments) is private and confidential, and is intended solely for the addressee. If you have received this communication in error please remove it and inform us via telephone or email. Although we take all possible steps to ensure mail and attachments are free from malicious content, malware and viruses, we cannot accept any responsibility whatsoever for any changes to content outwith our administrative bounds. The views represented within this mail are solely the view of the author and do not reflect the views of the organisation as a whole. Graham Technology plc Registered in Scotland company no. SC143434 Registered Office India of Inchinnan, Renfrewshire, Scotland PA4 9LH http://www.grahamtechnology.com
Reasons to structure
You may want to look over, and play with, the FM DITA plug in. It's a structured tool, obviously, but seems to be a rationally usable tool rather than an entire philosophy. Art On 2/15/07, Gordon McLean wrote: > "If you work in the tech industry and don't have time to learn, your fate is > sealed." > > I know what you are saying, but you are presuming that learning how to use a > technology is more important than learning whether or not that technology is > cost-effective to me in my current situation. > > On top of that, at the moment and to a lot of people, structured FrameMaker > talks the talk but -heavens to betsy- the walk looks like a complicated one. > When the walk is a little easier, I'll start to learn the steps. Just as I > did with HTML, then CSS. > > There is a brewing thought in here about Tipping Points but time marches > on.. > > So, that's what I have learned about structured FrameMaker, but then I tend > to let the early adopters do all the work and then swoop in later on. ;-) > > G > > > -Original Message- > Jeremy, I don't think that is harsh at all. What I think is harsh is the > constant discouragement from learning and professional development from > certain members of this list. It is so important for any tech writer to > learn about structured content, and I do not think I am any smarter than > anyone else just because I have expertise in structure. The only difference > with me is that I just spent the last five years being interested in it, and > I would like others to be interested in it as well. And that excuse about > "not having time" is really quite worn out. If you work in the tech industry > and don't have time to learn, your fate is sealed. > > And by the way, HTML is a perfect example of fully structured content, and > the web is a good example of the miracles that are possible with it. Thanks > for bringing that up. > -- Art Campbell art.campbell at gmail.com "... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl." -- Richard Thompson No disclaimers apply. DoD 358
Reasons To Structure
One more reason, at least for my team, and I did not see this in the thread (not directly said, anyway) is that we have a totally diff publishing model here at FedEx. Our model is stood on its head, so to speak. By that, I mean that our small group of writers function as a 'service bureau'. We are the only authors with Frame. However, our large body of 'authors', the SMEs, of course, author in Word. The, we must copy & paste their content into Frame, which amounts to a big waste of time _ theirs in fooling with all the formatting in Word, and ours by not being able to use their work, directly. So, we are trying to solve that problem by going to Structured Frame and DITA, and then use the XMetal collaboration tool, "XMAX," to provide a web-based interface in which they can author xml in a 'word-like' environment (we call it 'Bait & Switch'). Finally, we will use the Documentum CMS to manage it all (workflow and configuration management). I'll let you all know how it shakes out. Steve Gillespie, PMP Sr Information Development Analyst FedEx Express Memphis, TN 38125 901.434.9982
Reasons to Structure
All the reasons to use structured FrameMaker that people have submitted focus on the net benefits, which is probably the main reason why you would do this. However, here's a complementary take on it. As a lone writer, I did all the work to write an EDD and convert my unstructured doc to structured format. I continue to update the EDD to this day. Although occasionally frustrating, I got a great sense of accomplishment from the initial work, and continue to enjoy coming up with ways to improve how I manage my documents. If you enjoy the "tech" in tech writer and like working on the tools that make your day-to-day job easier, it's a lot of fun. (Going structured also lets you take advantage of some of the great tools that Russ Ward has written.) Fred -- Fred Wersan Senior Technical Writer MAK Technologies 68 Moulton St. Cambridge, MA 02138 617-876-8085 x 124
[BULK] RE: Reasons to structure
Russ West says: "It is so important for any tech writer to learn about structured content..." The funny thing is, in the majority of cases, we are not in a position to proselytize for or against structured documentation. That's usually decided several pay grades higher by contract deliverable or other edict. We rarely. If ever, get to choose or even recommend! But a TW who wishes to remain employable should be able to respond to structured or unstructured requirements by being able to work in both. The general trend in technical publishing, I predict (duh!), will require more automation, more reusability, more interchangeability of data, not less. If I had to bet on a winner in that horse race, my money would be on more structured documentation, not less, in our collective future. -Original Message- From: framers-bounces+randall.reed=forceprotection.net at lists.frameusers.com [mailto:framers-bounces+randall.reed=forceprotection.net at lists.frameuser s.com] On Behalf Of russ at weststreetconsulting.com Sent: Thursday, February 15, 2007 8:09 AM To: framers at lists.frameusers.com Subject: [BULK] RE: Reasons to structure Importance: Low Jeremy, I don't think that is harsh at all. What I think is harsh is the constant discouragement from learning and professional development from certain members of this list. It is so important for any tech writer to learn about structured content, and I do not think I am any smarter than anyone else just because I have expertise in structure. The only difference with me is that I just spent the last five years being interested in it, and I would like others to be interested in it as well. And that excuse about "not having time" is really quite worn out. If you work in the tech industry and don't have time to learn, your fate is sealed. And by the way, HTML is a perfect example of fully structured content, and the web is a good example of the miracles that are possible with it. Thanks for bringing that up. Message: 29 Date: Wed, 14 Feb 2007 17:46:00 -0800 From: "Jeremy H. Griffith" <jer...@omsys.com> Subject: Re: Reasons to Structure To: framers at lists.frameusers.com Message-ID: <2ib7t2p94cn4i7lv0j116s5svf7bhpld1u at 4ax.com> Content-Type: text/plain; charset=ISO-8859-1 On Wed, 14 Feb 2007 04:56:49 -0700, russ at weststreetconsulting.com wrote: >Jeremy Griffith wrote [referring to semantic markup]: > >>You can do the same with paragraph formats, too. But you can do all >>that in UNstructured docs just as easily as in structured. >>Maybe *more* easily, when you factor in the time to set up your >>structure, and to modify it when you make changes, which is major. >> >>I've only been able to identify one situation in which structured >>Frame can do this better than unstructured, and that's when you'd want >>nested element tags within a paragraph, since you cam't nest character >>formats. (There are easy workarounds for creating the equivalent of >>nested paragraph formats, such as using start/end formats and/or >>markers.) OTOH, I have yet to see a non-hypothetical case where such >>nested char formats were really needed... >> >>Structured Frame is designed for large pubs groups where standard >>document designs are required, perhaps for ISO 9000, perhaps for other >>corporate policy reasons. For smaller groups, and especially for lone >>writers, the setup costs (time and consultants) are likely to exceed >>the benefits, much like a CMS (Content Management System) can. There >>are excellent consultants around, many on this list, for whom it is a >>breeze. If you decide to go this way, hire one. >>It will prevent much anguish and hair loss. >This is misinformation, on nearly all counts. Isn't that a tad harsh, Russ? My point, which you appear to have missed, is that (as Richard said) semantic markup is good, *and* that you can do it in unstructured Frame. Do you deny this fact? I also said that for small groups, "the setup costs (time and consultants) are likely to exceed the benefits". I'll stand by that assessment, based on using Frame in both its unstructured *and* structured (formerly known as "FrameBuilder") forms over many, many years, originally on a Sun 2... I didn't say there are *no* benefits, just that the costs may be greater. Do you assert that the costs are always insignificant, then? >I am a lone writer who is completely dependent on structured Frame. >Without it, I would need at least twice the manpower to handle the >busywork that it does. Furthermore, I adhere to no industry standard >and make changes to my structured template frequently. All well and good... but what *else* are you? An expert in structure, perhaps? How long have you worked with structure? As I said, "There are exc
Reasons to Structure
Matt's question is, to some degree, academic and as a result list members have made many valid points, some totally at odds with others. (Isn't that the point of academia? :) In practice, the questions are: What will structure do for *my* problems and what will it cost to implement? I said the following recently in response to a similar question about XML over on techwr-l: For a long time my XML philosophy was, "If you need XML, you're already there." I've come off that belief as tools, best practices, and the like developed and evolved. That said, my current XML philosophy is "Don't deploy XML unless you have a clear set of goals and objectives and have a good understanding of the costs (effort, software, hardware, etc.) required to achieve those goals." In other words, XML for the sake of XML is a time and money pit. (My old philosophy was so much more catchy! ;( Find/replace XML with structure and you have my opinion on structure (less the catchy phrases). You better know why you're structuring your content and have a deep understanding of the obvious and hidden costs. Then it's just math ... is there ROI? -- Paul Nagai
Reasons to structure
If you work for a company that doesn't accept qualified recommendations for improvement from its staff, you should keep a resume up-to-date. No company can last too long if it doesn't embrace innovation from the lower levels. I think the truth is, actually, that in the majority of cases, tech writers are not qualified to proselytize on structure, because they haven't really learned about it yet. Hence my original point, several postings ago. You have to understand it to present a convincing business case (show them the money, as it were). In the past several years, I've had relatively little difficulty getting acceptance from management for new tools, methods, etc., because I understand the benefits and can clearly enumerate the reasons for doing it. I would like all tech writers to be this way, because I don't want us to be second class in the arena of ideas. When it comes to tools and methods involved with our work, we should be the primary influence on what happens. The key is, though, we need to know what we are talking about first. So I say, get in there and learn. I don't believe for a second that there are only a select few of us that can understand simple tools like structured Frame. You just need to have the desire and understanding of how important it is. Original Message Subject: RE: Reasons to structure From: "Randall C. Reed" <randall.r...@forceprotection.net> Date: Thu, February 15, 2007 9:11 am To: , Russ West says: "It is so important for any tech writer to learn about structured content..." The funny thing is, in the majority of cases, we are not in a position to proselytize for or against structured documentation. That's usually decided several pay grades higher by contract deliverable or other edict. We rarely. If ever, get to choose or even recommend! But a TW who wishes to remain employable should be able to respond to structured or unstructured requirements by being able to work in both. The general trend in technical publishing, I predict (duh!), will require more automation, more reusability, more interchangeability of data, not less. If I had to bet on a winner in that horse race, my money would be on more structured documentation, not less, in our collective future.
Reasons to structure
I'm on the FM-DITA mailing list Art, and was invovled about a year or two ago when it was just starting out. I still keep on top of things, but in my last place we switched to AuthorIT as it meet our needs. My current position already has a structured FrameMaker setup, so I've missed the chance to 'learn it hands on'. I'm not against structured FrameMaker, but, and I said this in the early DITA days as well, it's a bit daunting for some people and would benefit from a simple way to 'get into it'. I agree that DITA is probably that very way. G -Original Message- You may want to look over, and play with, the FM DITA plug in. It's a structured tool, obviously, but seems to be a rationally usable tool rather than an entire philosophy. Art On 2/15/07, Gordon McLean wrote: > "If you work in the tech industry and don't have time to learn, your > fate is sealed." > > I know what you are saying, but you are presuming that learning how to > use a technology is more important than learning whether or not that > technology is cost-effective to me in my current situation. > > On top of that, at the moment and to a lot of people, structured > FrameMaker talks the talk but -heavens to betsy- the walk looks like a complicated one. > When the walk is a little easier, I'll start to learn the steps. Just > as I did with HTML, then CSS. > > There is a brewing thought in here about Tipping Points but time > marches on.. > This email (and any attachments) is private and confidential, and is intended solely for the addressee. If you have received this communication in error please remove it and inform us via telephone or email. Although we take all possible steps to ensure mail and attachments are free from malicious content, malware and viruses, we cannot accept any responsibility whatsoever for any changes to content outwith our administrative bounds. The views represented within this mail are solely the view of the author and do not reflect the views of the organisation as a whole. Graham Technology plc Registered in Scotland company no. SC143434 Registered Office India of Inchinnan, Renfrewshire, Scotland PA4 9LH http://www.grahamtechnology.com
Reasons to structure: another point of view
I've written documentation in the Detroit area for over 20 years and although I know structured Frame and use a custom XML format with Epic Editor/Manager in my present position, I find that most employers here hardly know what FrameMaker is, let alone anything about structured Frame and/or XML/reuse. Time and time again I see jobs that require only a basic knowledge of Ms Office, and I ignore them because I don't think these employers take documentation seriously. Admittedly, Detroit is in bad shape these days, but from my side of the tracks I see few employers who require Frame experience of any kind. My advice is not to worry about attaining Frame guruhood. Instead, diversify into training, biomedical, and other areas that will give you an edge when most tech writing jobs have gone to India. Learn Adobe Flash and Captivate to support those self-paced and instructor-led job opportunities that seem to be floating our way; take Instructional Design courses. It may be a slow boat, but outsourcing IS headed your way; the company I now work for requires that we seek out tech writers in India, even though I'm told that universities there don't offer much in the necessary education. All we can do is hope that those of us with the company for years aren't canned to benefit the next IPO. Sorry for the dire forecast, but the East and West coasts can't be far behind. --Sean Pollock -Original Message- From: framers-bounces+spolloc1=hotmail@lists.frameusers.com [mailto:framers-bounces+spolloc1=hotmail.com at lists.frameusers.com] On Behalf Of russ at weststreetconsulting.com Sent: Thursday, February 15, 2007 12:19 PM To: Randall C. Reed Cc: framers at lists.frameusers.com Subject: RE: Reasons to structure If you work for a company that doesn't accept qualified recommendations for improvement from its staff, you should keep a resume up-to-date. No company can last too long if it doesn't embrace innovation from the lower levels. I think the truth is, actually, that in the majority of cases, tech writers are not qualified to proselytize on structure, because they haven't really learned about it yet. Hence my original point, several postings ago. You have to understand it to present a convincing business case (show them the money, as it were). In the past several years, I've had relatively little difficulty getting acceptance from management for new tools, methods, etc., because I understand the benefits and can clearly enumerate the reasons for doing it. I would like all tech writers to be this way, because I don't want us to be second class in the arena of ideas. When it comes to tools and methods involved with our work, we should be the primary influence on what happens. The key is, though, we need to know what we are talking about first. So I say, get in there and learn. I don't believe for a second that there are only a select few of us that can understand simple tools like structured Frame. You just need to have the desire and understanding of how important it is. Original Message Subject: RE: Reasons to structure From: "Randall C. Reed" <randall.r...@forceprotection.net> Date: Thu, February 15, 2007 9:11 am To: , Russ West says: "It is so important for any tech writer to learn about structured content..." The funny thing is, in the majority of cases, we are not in a position to proselytize for or against structured documentation. That's usually decided several pay grades higher by contract deliverable or other edict. We rarely. If ever, get to choose or even recommend! But a TW who wishes to remain employable should be able to respond to structured or unstructured requirements by being able to work in both. The general trend in technical publishing, I predict (duh!), will require more automation, more reusability, more interchangeability of data, not less. If I had to bet on a winner in that horse race, my money would be on more structured documentation, not less, in our collective future. ___ You are currently subscribed to Framers as spolloc1 at hotmail.com. Send list messages to framers at lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscribe at lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/spolloc1%40hotmail.com Send administrative questions to listadmin at frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
RE: Reasons to Structure
Jeremy Griffith, write: snip You can do the same with paragraph formats, too. But you can do all that in UNstructured docs just as easily as in structured. Maybe *more* easily, when you factor in the time to set up your structure, and to modify it when you make changes, which is major. I've only been able to identify one situation in which structured Frame can do this better than unstructured, and that's when you'd want nested element tags within a paragraph, since you cam't nest character formats. (There are easy workarounds for creating the equivalent of nested paragraph formats, such as using start/end formats and/or markers.) OTOH, I have yet to see a non-hypothetical case where such nested char formats were really needed... Structured Frame is designed for large pubs groups where standard document designs are required, perhaps for ISO 9000, perhaps for other corporate policy reasons. For smaller groups, and especially for lone writers, the setup costs (time and consultants) are likely to exceed the benefits, much like a CMS (Content Management System) can. There are excellent consultants around, many on this list, for whom it is a breeze. If you decide to go this way, hire one. It will prevent much anguish and hair loss. -- Jeremy H. Griffith, at Omni Systems Inc. [EMAIL PROTECTED] http://www.omsys.com/ snip This is misinformation, on nearly all counts. I am a lone writer who is completely dependent on structured Frame. Without it, I would need at least twice the manpower to handle the busywork that it does. Furthermore, I adhere to no industry standard and make changes to my structured template frequently. Here's is just one tiny example of what it does for me, not even the tip of the iceberg... I have an element tag called li (list item). When I insert, move, or copy it anywhere, this element: - Automatically checks to see if it is in a lone bullet list. If so, it automatically applies a bullet item format - If not, checks to see if it is in a bullet list, nested in another bullet list. If so, it applies a nested bullet format - If not, checks to see if it is in a bullet list, nested in a number list. If so, it applies a special nested bullet format for inside number list - If not, checks to see if it is in a number list. If so, it then checks to see if it is the first one. If it is, it automatically applies a number restart format. Otherwise, it applies the regular number format - If not, checks to see if it is in a nested number list. If so, it checks to see if it is the first one. If it is, it automatically applies a subnumber restart format. Otherwise, it automatically applies a regular subnumber format. - If not, checks to see if it is in a nested number list, under a bullet list. If so, it then checks to see if it is the first one. If it is, it automatically applies a special subnumber format for restarting. If not, it applies a regular subnumber format. That's just a sampling. And by the way, I didn't even mention tables. If the element discovers that it is in a table, it goes through this identical decision process with a whole different set of table-related formats. So there is something like 16 different paragraph formats, all represented by one tag. I never, ever have to think about the paragraph format. I just know that I need a list item and stick it in there. The technology decides on the format tag for me. Maybe you guys don't use lists, but I use lots of them. And this is a huge timesaver with every single list item. And just for a second, think about this... if you have to think about starting a number list at 1, there is something obsolete about your tool. That's a pretty simple request, in the grand scheme of things. Granted, the setup costs for me are minimal now, because I have the skill set. But that is the whole point of these occasional rants... you just have to get in there and learn, because that's when it becomes a breeze. Don't buy those arguments from people who say it isn't worth the time... they made the same exact argument some decades ago when we were all using typewriters and thinking about computers. They could (and do) make the same exact arguments now when we are working in Word and thinking about Framemaker. Of course it takes time to ramp up, but when it is so obviously the way of the future, the investment is worth it. If you don't make that investment, someone who did will eventually be doing your job. Two final points... - I'll retract much of what I said if you can provide a single recent example of anything groundbreaking in the area of techcomm that specifically involved unstructured content. - Always beware of the typewriter salesman when you are reading the computer brochure. Russ -- ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To
RE: Reasons to Structure
Ok, I'll hoof in line and sinker. I recently wrote a series of articles on structured FrameMaker, and here's what I put under 'Why should I use structured documents?'. The ordering is not significant, and some points have already been covered by others: . A much greater level of automation becomes possible, such as the context-dependent application of formatting [mentioned above]. . A document's structure can be validated, that is, checked against the structure definition and any errors and omissions flagged. . Structure allows design devices that would be tedious and error-prone to apply in unstructured FrameMaker to be wrapped in elements and used much more easily. . The ability to interact with documents at a structural level makes edits to the structure easier and less error-prone, as well as making objects like markers much easier to select. . Formatting rules within the structure definition allow document content to be reformatted in response to structural changes, for example changing one element into another with a single command and having all child elements reformat automatically. . Meaning can be introduced into document structures. For example, the documentation of a software programming interface might include name, interface definition, parameter definition list, usage and error messages for each procedure call. Such elements can be given descriptive names in the structure definition, and completeness can be checked and enforced. . Locally-applied formatting can be removed by reapplying the structure definition to a document. . Document contents can be repurposed much more easily. . Extra information about parts of a document can be introduced through the use of attributes, data fields that 'belong' to elements but which do not appear in the document itself. . Inter-working with document tagging formats such as SGML and XML becomes possible. I see that I omitted to mention the obvious point that structure allows you to separate structure and presentation under two separate systems of control. -- Steve ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Reasons to Structure
Matt, I do both structured and unstructured. The need for that depends IMHO on the contents and structure (or lack of) in the document(s). However, where I have been using structure (and then I ususally set all the formatting from within the EDD and avoid using paragraph format tags), all updating is much easier, and my revisors are much quicker to make their updates. This was the short version. Don't have the time for the long version. ;-) Bodvar On 2/12/07, MATT TODD [EMAIL PROTECTED] wrote: All right...tell me good, solid reasons why a company would want to structure their documents. With my limited knowledge, I know structure effectively controls styles, fonts, etc...but I could manage that myself without structure. By extension, I know style control also controls content location because particular types of writing usually use a particular style...but I can also manage that myself. I know structure is designed to encourage single-sourcing, but I'm already headed in that direction without structure. I'm convinced with time and continuing documentation analysis, I can parse our documentation so duplicate verbiage in all our documents imports from one source. I can do that without structure. I can use conditional text to further cut down duplicate verbiage; it requires no structure. I can buy scripts or third-party software to automate documentation procedures without resorting to structure. So tell me...why structure documentation? I don't know enough to answer that question, and neither do my bosses. What's so great about it? What capabilities does it offer that demand its use? Right now, I'm just doing what I'm told, but it's always nice to found actions on solid reason. Matt I'm working with legacy documentation created in Word and FM 7.0 unstructured. The goal is FM 7.0 structured. Whose goal is this, and why? I've seen the gee whiz demonstrations from Adobe reps and been utterly convinced that I Need Structured Docs Now! only to return to my pdf-output-only client projects that have no real need for structured Frame. Before committing, make sure there's a business case for structuring. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/bodvar%40gmail.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Reasons to Structure
That makes sense. Thanks. -Original Message- From: Ridder, Fred [mailto:[EMAIL PROTECTED] Subject: RE: Reasons to Structure The point is that you tag a UI element as a UI element because it is a UI element. You make it bold (or whatever) at a later point in the process based on how you choose to format the semantically tagged elements for a given deliverable. The element itself is tagged according to what kind of information it is, so the tagging is basically meta-information that has added value to your content because it can be used in all sorts of post-processing operations. Semantic tagging of in-line elements (like names of parameters and API functions) is so valuable that our pubs group was doing it in our Word documentation many before we transitioned to Frame, which was several years before we were acquired by Intel and even more years before Intel sold off that business unit and all those documents. My opinions only; I don't speak for Intel. Fred Ridder (fred dot ridder at intel dot com) Intel Parsippany, NJ -Original Message- Subject: RE: Reasons to Structure Sorry to be so delinquent in responding to this; I have my excuses. Some of us actually LIKE the left-brain right-brain gear shifting and are quite efficient at it. Mind you, I am a great proponent of structured authoring in theory and a miserable practitioner. Maybe it is because I am blessed with a mind that is peculiarly both analytical and creative in more-or-less equal measure. Besides-with the caveat that I have not actually experienced *enforced* structured authoring, per sé-if you need to format a word or phrase for emphasis or for special recognition (such as bolding UI elements), don't you still have to tag that content somewhere? So where is the great advantage? As I understand structured authoring (with my admittedly limited understanding), its strengths seem to lie more in the realm of freeing the author from having to make specific adhoc formatting decisions that may or (more likely) may not be consistent. That, and enforcing certain rules about what content is required, accepted, optional, etc. Is it not so? Chuck Beck ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Reasons to Structure
Matt, Another major benefit of structured FrameMaker is context sensitive formatting, which I believe was mentioned before by another forum member. An added detail is that you can reuse generic element tags which will look dramatically different in different contexts. In unstructured FrameMaker, it is not uncommon to use 3 paragraph tags for a 3-level nested list: [bulletlist] contains [dashlist] which contains [sqbulletlist]. In structured FrameMaker you could use a generic element [list] and have format rules in the EDD determine that a second level list contained within a list would be tagged with paragraph [dashlist] while a third level list contained within a list contained within a list would be tagged with paragraph [sqbulletlist]. In the structured editor, if you were to select a 3rd level nested [list] element and dynamically drag it to the 2nd level, it will automatically reformat and be tagged with [dashlist] instead of [sqbulletlist]. The key benefit is that users have fewer tags to deal with. In an actual customer example, we had a client who was using over 130 paragraph tags (including paragraph variants like [BulletListLast], [DashListLast], [WhateveListLast].) In most of these cases, such paragraphs were identical to normal list paragraphs, but had extra space below paragraph to ensure that the last item in the list did not slam into the next paragraph. We developed a structured FrameMaker application for this client with format rules in the EDD which ensured that the last [ListItem] element contained in a [List] element has extra space below it. As a result, our client moved from using over 130 PARAGRAPH tags to about 40 frequently used ELEMENT tags. Our client observed that it became easier for new staff to master rather complex document template rules. NOTE: this client had about 5 tech writers working on very high volume documentation with consistent formatting and structure. Average FrameMaker books were about 400pp long. Another benefit from the transition to structure was that the tech writers produced more consistent document structure. Due to the lack of random character level format overrides, there was less touch up to formatting in post-translation documents, which reduced billable time on translation projects. Format proofing time was greatly reduced, which was magnified by the 11 languages XML extracted from FrameMaker was translated into. Structured FrameMaker *does* require a lot of work up front, establishing the EDD if you have complex formatting, but it is well worth the effort and you will gain a return on investment fairly quickly. I hope that this helps. MATT TODD [EMAIL PROTECTED] wrote: [snip] So tell me...why structure documentation? I don't know enough to answer that question, and neither do my bosses. What's so great about it? What capabilities does it offer that demand its use? Right now, I'm just doing what I'm told, but it's always nice to found actions on solid reason. Matt Maxwell Hoffmann Manager of Consulting Training Solutions ENLASO Corporation T: 805 494 9571 * F: 805 435 1920 E: [EMAIL PROTECTED] ENLASO Corporation provides quality enterprise language solutions and exceeds client expectations through continuing research, development, and implementation of effective localization processes and technologies. Visit: www.translate.com for more information or to subscribe to our complimentary localization newsletter. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Reasons to Structure
Maxwell Hoffmann wrote: Matt, Another major benefit of structured FrameMaker is context sensitive formatting, which I believe was mentioned before by another forum member. An added detail is that you can reuse generic element tags which will look dramatically different in different contexts. Hi, Matt: Maxwell's point and example about how useful context-sensitive formatting rules can be is right on. However, this ability to interpret the rules you create in your EDD, blurs the line between several aspects of structured FrameMaker. Structured element design is required so the rules know each element's identity, or definition. The rules can't function without clear instructions and clear identification of each element. It's something like you can't have a terrific automatic zillion-position-adjustable-programmable-memory car seat without having the car, the power to run the seat, and having spent the time learning to adjust the seat, to capture the settings for each user, and how to recall each user's setting. Context-sensitive formatting is terrific! No doubt about it. But, you get the most return on your learning investment by having documents that often require the kind of manual effort that's worth turning over to the smart rules-inforcer, to gain efficiency. HTH Regards, Peter Gold KnowHow ProServices ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Reasons to Structure
No one has mentioned the potential for greatly improving writer productivity, as well as eliminating format overrides. Once authors are up to speed on using the structure view and the element catalog, they're freed from the entire formatting burden (if the EDD specifies context-based format rules). I see no reason why this productivity advantage would diminish for relatively small documents. And, unlike unstructured Frame, re-importing the EDD into a structured document with Remove Format Overrides turned on will eliminate every single instance in which authors overrode the EDD-specified formatting. When authors realize this step is part of the review process, they know the jig is up. - ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Reasons to Structure
--- Charles Beck [EMAIL PROTECTED] wrote: Besides-with the caveat that I have not actually experienced *enforced* structured authoring, per sé-if you need to format a word or phrase for emphasis or for special recognition (such as bolding UI elements), don't you still have to tag that content somewhere? So where is the great advantage? === Semantic tagging of a word or phrase can be implemented by wrapping it with an EDD-defined text-range element whose element name describes the semantic type. A format rule in the EDD automatically applies the correct format to it. As I understand structured authoring (with my admittedly limited understanding), its strengths seem to lie more in the realm of freeing the author from having to make specific adhoc formatting decisions that may or (more likely) may not be consistent. That, and enforcing certain rules about what content is required, accepted, optional, etc. === In a properly designed EDD, there is no such thing as ad-hoc formatting. That is, Format rules define all formatting. These format rules can be based on one or more of the following: element name, element context, element attribute value(s), and format change lists referenced from within the format rules. Typically, full use of these capabilities can drastically reduce the number of paragraph and character formats required in a FrameMaker template. I could go on to describe numerous other advantages of this approach to formatting. Typically, full use of ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Reasons to Structure
On Wed, 14 Feb 2007 04:56:49 -0700, [EMAIL PROTECTED] wrote: Jeremy Griffith wrote [referring to semantic markup]: You can do the same with paragraph formats, too. But you can do all that in UNstructured docs just as easily as in structured. Maybe *more* easily, when you factor in the time to set up your structure, and to modify it when you make changes, which is major. I've only been able to identify one situation in which structured Frame can do this better than unstructured, and that's when you'd want nested element tags within a paragraph, since you cam't nest character formats. (There are easy workarounds for creating the equivalent of nested paragraph formats, such as using start/end formats and/or markers.) OTOH, I have yet to see a non-hypothetical case where such nested char formats were really needed... Structured Frame is designed for large pubs groups where standard document designs are required, perhaps for ISO 9000, perhaps for other corporate policy reasons. For smaller groups, and especially for lone writers, the setup costs (time and consultants) are likely to exceed the benefits, much like a CMS (Content Management System) can. There are excellent consultants around, many on this list, for whom it is a breeze. If you decide to go this way, hire one. It will prevent much anguish and hair loss. This is misinformation, on nearly all counts. Isn't that a tad harsh, Russ? My point, which you appear to have missed, is that (as Richard said) semantic markup is good, *and* that you can do it in unstructured Frame. Do you deny this fact? I also said that for small groups, the setup costs (time and consultants) are likely to exceed the benefits. I'll stand by that assessment, based on using Frame in both its unstructured *and* structured (formerly known as FrameBuilder) forms over many, many years, originally on a Sun 2... I didn't say there are *no* benefits, just that the costs may be greater. Do you assert that the costs are always insignificant, then? I am a lone writer who is completely dependent on structured Frame. Without it, I would need at least twice the manpower to handle the busywork that it does. Furthermore, I adhere to no industry standard and make changes to my structured template frequently. All well and good... but what *else* are you? An expert in structure, perhaps? How long have you worked with structure? As I said, There are excellent consultants around, many on this list, for whom it is a breeze. You are one of the four or five I'd think of first... Here's the first line on your home page: Welcome to West Street Consulting, your home for structured FrameMaker® plugins and other utilities. I've also written plugins that work with structured Frame (Mif2Go does, just fine), but I hardly consider myself a representative Frame user... nor would I assume that everyone would have as easy a time as I do. Do you say it's easy for everyone? Granted, the setup costs for me are minimal now, because I have the skill set. My point exactly. That's why I said hire a consultant. Do you think consultants are unnecessary? vbg But that is the whole point of these occasional rants... you just have to get in there and learn, because that's when it becomes a breeze. Assuming, that is, that you *have* the time. Many of our colleagues, having survived downsizing from ten writers to two with no decrease of workload, do not. And if you do, is that time better spent on learning nifty new tools, or on improving the docs you're paid to write? One size does *not* fit all. If you have a genuine *business* case for going to structured Frame (or if you are a hacker at heart, like you and I), go for it. ;-) Of course it takes time to ramp up, but when it is so obviously the way of the future, ... This makes me feel old. g Well, I *am* old... old enough to remember any number of obvious advances that went nowhere. The future has many ways... most of which we won't recognize until we get there. Here's a little related snippet from [XML-DEV] today: [Michael Chanpion:] On the other hand, this is more or less the story of CORBA lots of time and money spent on something that has vastly underperformed relative to its initial hype. [Elliotte Rusty Harold:] Exactly, and that's hardly the only example of lots of corporate money being fed into the shredder. That's in the current More predictions to mull over thread... Two final points... - I'll retract much of what I said if you can provide a single recent example of anything groundbreaking in the area of techcomm that specifically involved unstructured content. The Web? You don't consider HTML an example of structured content, do you? It qualifies in only the most technical sense... and most pages violate even its simple DTDs grossly. Or maybe it's not recent enough for you? - Always beware of the typewriter salesman when you are reading the computer brochure. You consider
Reasons to Structure
Jeremy Griffith, write: You can do the same with paragraph formats, too. But you can do all that in UNstructured docs just as easily as in structured. Maybe *more* easily, when you factor in the time to set up your structure, and to modify it when you make changes, which is major. I've only been able to identify one situation in which structured Frame can do this better than unstructured, and that's when you'd want nested element tags within a paragraph, since you cam't nest character formats. (There are easy workarounds for creating the equivalent of nested paragraph formats, such as using start/end formats and/or markers.) OTOH, I have yet to see a non-hypothetical case where such nested char formats were really needed... Structured Frame is designed for large pubs groups where standard document designs are required, perhaps for ISO 9000, perhaps for other corporate policy reasons. For smaller groups, and especially for lone writers, the setup costs (time and consultants) are likely to exceed the benefits, much like a CMS (Content Management System) can. There are excellent consultants around, many on this list, for whom it is a breeze. If you decide to go this way, hire one. It will prevent much anguish and hair loss. -- Jeremy H. Griffith, at Omni Systems Inc. http://www.omsys.com/ >> >> This is misinformation, on nearly all counts. I am a lone writer who is completely dependent on structured Frame. Without it, I would need at least twice the manpower to handle the busywork that it does. Furthermore, I adhere to no industry standard and make changes to my structured template frequently. Here's is just one tiny example of what it does for me, not even the tip of the iceberg... I have an element tag called "li" (list item). When I insert, move, or copy it anywhere, this element: - Automatically checks to see if it is in a lone bullet list. If so, it automatically applies a bullet item format - If not, checks to see if it is in a bullet list, nested in another bullet list. If so, it applies a nested bullet format - If not, checks to see if it is in a bullet list, nested in a number list. If so, it applies a special nested bullet format for inside number list - If not, checks to see if it is in a number list. If so, it then checks to see if it is the first one. If it is, it automatically applies a number restart format. Otherwise, it applies the regular number format - If not, checks to see if it is in a nested number list. If so, it checks to see if it is the first one. If it is, it automatically applies a subnumber restart format. Otherwise, it automatically applies a regular subnumber format. - If not, checks to see if it is in a nested number list, under a bullet list. If so, it then checks to see if it is the first one. If it is, it automatically applies a special subnumber format for restarting. If not, it applies a regular subnumber format. That's just a sampling. And by the way, I didn't even mention tables. If the element discovers that it is in a table, it goes through this identical decision process with a whole different set of table-related formats. So there is something like 16 different paragraph formats, all represented by one tag. I never, ever have to think about the paragraph format. I just know that I need a list item and stick it in there. The technology decides on the format tag for me. Maybe you guys don't use lists, but I use lots of them. And this is a huge timesaver with every single list item. And just for a second, think about this... if you have to think about starting a number list at "1", there is something obsolete about your tool. That's a pretty simple request, in the grand scheme of things. Granted, the setup costs for me are minimal now, because I have the skill set. But that is the whole point of these occasional rants... you just have to get in there and learn, because that's when it becomes a breeze. Don't buy those arguments from people who say it isn't worth the time... they made the same exact argument some decades ago when we were all using typewriters and thinking about computers. They could (and do) make the same exact arguments now when we are working in Word and thinking about Framemaker. Of course it takes time to ramp up, but when it is so obviously the way of the future, the investment is worth it. If you don't make that investment, someone who did will eventually be doing your job. Two final points... - I'll retract much of what I said if you can provide a single recent example of anything groundbreaking in the area of techcomm that specifically involved unstructured content. - Always beware of the typewriter salesman when you are reading the computer brochure. Russ --
Reasons to Structure
Ok, I'll hoof in line and sinker. I recently wrote a series of articles on structured FrameMaker, and here's what I put under 'Why should I use structured documents?'. The ordering is not significant, and some points have already been covered by others: . A much greater level of automation becomes possible, such as the context-dependent application of formatting [mentioned above]. . A document's structure can be validated, that is, checked against the structure definition and any errors and omissions flagged. . Structure allows design devices that would be tedious and error-prone to apply in unstructured FrameMaker to be wrapped in elements and used much more easily. . The ability to interact with documents at a structural level makes edits to the structure easier and less error-prone, as well as making objects like markers much easier to select. . Formatting rules within the structure definition allow document content to be reformatted in response to structural changes, for example changing one element into another with a single command and having all child elements reformat automatically. . Meaning can be introduced into document structures. For example, the documentation of a software programming interface might include name, interface definition, parameter definition list, usage and error messages for each procedure call. Such elements can be given descriptive names in the structure definition, and completeness can be checked and enforced. . Locally-applied formatting can be removed by reapplying the structure definition to a document. . Document contents can be repurposed much more easily. . Extra information about parts of a document can be introduced through the use of attributes, data fields that 'belong' to elements but which do not appear in the document itself. . Inter-working with document tagging formats such as SGML and XML becomes possible. I see that I omitted to mention the obvious point that structure allows you to separate structure and presentation under two separate systems of control. -- Steve
Reasons to Structure
Matt, I do both structured and unstructured. The need for that depends IMHO on the contents and "structure" (or lack of) in the document(s). However, where I have been using structure (and then I ususally set all the formatting from within the EDD and avoid using paragraph format tags), all updating is much easier, and my revisors are much quicker to make their updates. This was the short version. Don't have the time for the long version. ;-) Bodvar On 2/12/07, MATT TODD wrote: > All right...tell me good, solid reasons why a company would want to > structure their documents. With my limited knowledge, I know structure > effectively controls styles, fonts, etc...but I could manage that myself > without structure. By extension, I know style control also controls > content location because particular types of writing usually use a > particular style...but I can also manage that myself. I know structure > is designed to encourage single-sourcing, but I'm already headed in that > direction without structure. I'm convinced with time and continuing > documentation analysis, I can parse our documentation so duplicate > verbiage in all our documents imports from one source. I can do that > without structure. I can use conditional text to further cut down > duplicate verbiage; it requires no structure. I can buy scripts or > third-party software to automate documentation procedures without > resorting to structure. > > So tell me...why structure documentation? I don't know enough to answer > that question, and neither do my bosses. What's so great about it? What > capabilities does it offer that demand its use? Right now, I'm just > doing what I'm told, but it's always nice to found actions on solid > reason. > > Matt > > > I'm working with legacy documentation created in Word and FM 7.0 > > unstructured. The goal is FM 7.0 structured. > > Whose goal is this, and why? I've seen the gee whiz demonstrations from > Adobe reps and been utterly convinced that I Need Structured Docs Now! > only to return to my pdf-output-only client projects that have no real > need for structured Frame. Before committing, make sure there's a > business case for structuring. > > ___ > > > You are currently subscribed to Framers as bodvar at gmail.com. > > Send list messages to framers at lists.frameusers.com. > > To unsubscribe send a blank email to > framers-unsubscribe at lists.frameusers.com > or visit > http://lists.frameusers.com/mailman/options/framers/bodvar%40gmail.com > > Send administrative questions to listadmin at frameusers.com. Visit > http://www.frameusers.com/ for more resources and info. >
Reasons to Structure
>>MATT TODD wrote: >>[snip] >> >>So tell me...why structure documentation? I don't know enough >>to answer that question, and neither do my bosses. What's so >>great about it? >>What capabilities does it offer that demand its use? Right now, >>I'm just doing what I'm told, but it's always nice to found >>actions on solid reason. 1) It's the only way you can manage large amounts of content in a CMS. Picture having 10,000 pieces of content being shared amoung 20 writers throughout five different writing locations, and you want to modify one of the pieces. Who else is using it? Who will it affect? 2) Take that same amount of content. Before you start writing something from scratch, wouldn't it be nicer (and quicker, and cheaper) to select a piece already written and drop it into your document? It's already been reviewed and it's accurate. 3) You receive notification that your product line is now being sold in another country and it has to be localized. Would it make a difference in the speed and cost if you knew that 40% of the content is shared amoung multiple documents and 40% of the content only has to be localized once rather that four times because it is used in four documents? You say nothing about your business, your document volume, nor your writing process. Are you a single writer at a single location? Don't do it...it brings nothing to your table that isn't superceded by the thousands of dollars it will cost you to convert. OTOH...multiple writers in multiple locations? Maybe. One of the main criteria? You must be writing according to a defined process and want to repeat the process over and over, not writing depending on what you feel like doing at any point in time. Don't get me wrong...the later description in the above paragraph is not bad...it's just different than the former. John Posada Senior Technical Writer "I think the problem, to be quite honest with you, is that you've never actually known what the question is."
Reasons to Structure
That makes sense. Thanks. -Original Message- From: Ridder, Fred [mailto:fred.rid...@intel.com] Subject: RE: Reasons to Structure The point is that you tag a UI element as a UI element because it is a UI element. You make it bold (or whatever) at a later point in the process based on how you choose to format the semantically tagged elements for a given deliverable. The element itself is tagged according to what kind of information it is, so the tagging is basically meta-information that has added value to your content because it can be used in all sorts of post-processing operations. Semantic tagging of in-line elements (like names of parameters and API functions) is so valuable that our pubs group was doing it in our Word documentation many before we transitioned to Frame, which was several years before we were acquired by Intel and even more years before Intel sold off that business unit and all those documents. My opinions only; I don't speak for Intel. Fred Ridder (fred dot ridder at intel dot com) Intel Parsippany, NJ -Original Message- Subject: RE: Reasons to Structure Sorry to be so delinquent in responding to this; I have my excuses. Some of us actually LIKE the left-brain right-brain gear shifting and are quite efficient at it. Mind you, I am a great proponent of structured authoring in theory and a miserable practitioner. Maybe it is because I am blessed with a mind that is peculiarly both analytical and creative in more-or-less equal measure. Besides-with the caveat that I have not actually experienced *enforced* structured authoring, per s?-if you need to format a word or phrase for emphasis or for special recognition (such as bolding UI elements), don't you still have to tag that content somewhere? So where is the great advantage? As I understand structured authoring (with my admittedly limited understanding), its strengths seem to lie more in the realm of freeing the author from having to make specific adhoc formatting decisions that may or (more likely) may not be consistent. That, and enforcing certain rules about what content is required, accepted, optional, etc. Is it not so? Chuck Beck
Reasons to Structure
Matt, Another major benefit of structured FrameMaker is "context sensitive formatting," which I believe was mentioned before by another forum member. An added detail is that you can reuse "generic" element tags which will look dramatically different in different contexts. In unstructured FrameMaker, it is not uncommon to use 3 paragraph tags for a 3-level nested list: [bulletlist] "contains" [dashlist] which "contains" [sqbulletlist]. In structured FrameMaker you could use a generic element [list] and have format rules in the EDD determine that a "second level" list contained within a list would be tagged with paragraph [dashlist] while a "third level" list contained within a list contained within a list would be tagged with paragraph [sqbulletlist]. In the structured editor, if you were to select a 3rd level nested [list] element and dynamically drag it to the 2nd level, it will automatically reformat and be tagged with [dashlist] instead of [sqbulletlist]. The key benefit is that users have fewer tags to deal with. In an actual customer example, we had a client who was using over 130 paragraph tags (including paragraph variants like [BulletListLast], [DashListLast], [WhateveListLast].) In most of these cases, such paragraphs were identical to normal list paragraphs, but had extra space below paragraph to ensure that the last item in the list did not "slam" into the next paragraph. We developed a structured FrameMaker application for this client with format rules in the EDD which ensured that the last [ListItem] element contained in a [List] element has extra space below it. As a result, our client moved from using over 130 PARAGRAPH tags to about 40 frequently used ELEMENT tags. Our client observed that it became easier for new staff to master rather complex document template rules. NOTE: this client had about 5 tech writers working on very high volume documentation with consistent formatting and structure. Average FrameMaker books were about 400pp long. Another benefit from the transition to structure was that the tech writers produced more consistent document structure. Due to the lack of random character level format overrides, there was less "touch up" to formatting in post-translation documents, which reduced billable time on translation projects. Format proofing time was greatly reduced, which was magnified by the 11 languages XML extracted from FrameMaker was translated into. Structured FrameMaker *does* require a lot of work up front, establishing the EDD if you have complex formatting, but it is well worth the effort and you will gain a return on investment fairly quickly. I hope that this helps. >MATT TODD wrote: >[snip] > >So tell me...why structure documentation? I don't know enough to answer >that question, and neither do my bosses. What's so great about it? What >capabilities does it offer that demand its use? Right now, I'm just >doing what I'm told, but it's always nice to found actions on solid >reason. > >Matt Maxwell Hoffmann Manager of Consulting & Training Solutions ENLASO Corporation T: 805 494 9571 * F: 805 435 1920 E: mhoffmann at translate.com ENLASO Corporation provides quality enterprise language solutions and exceeds client expectations through continuing research, development, and implementation of effective localization processes and technologies. Visit: www.translate.com for more information or to subscribe to our complimentary localization newsletter.
Reasons to Structure
Maxwell Hoffmann wrote: > Matt, > > Another major benefit of structured FrameMaker is "context sensitive > formatting," which I believe was mentioned before by another forum > member. An added detail is that you can reuse "generic" element tags > which will look dramatically different in different contexts. > > Hi, Matt: Maxwell's point and example about how useful context-sensitive formatting rules can be is right on. However, this ability to interpret the rules you create in your EDD, blurs the line between several aspects of structured FrameMaker. Structured element design is required so the rules know each element's "identity," or definition. The rules can't function without clear instructions and clear identification of each element. It's something like you can't have a terrific automatic zillion-position-adjustable-programmable-memory car seat without having the car, the power to run the seat, and having spent the time learning to adjust the seat, to capture the settings for each user, and how to recall each user's setting. Context-sensitive formatting is terrific! No doubt about it. But, you get the most return on your learning investment by having documents that often require the kind of manual effort that's worth turning over to the smart rules-inforcer, to gain efficiency. HTH Regards, Peter Gold KnowHow ProServices
Reasons to Structure
No one has mentioned the potential for greatly improving writer productivity, as well as eliminating format overrides. Once authors are up to speed on using the structure view and the element catalog, they're freed from the entire formatting burden (if the EDD specifies context-based format rules). I see no reason why this productivity advantage would diminish for relatively small documents. And, unlike unstructured Frame, re-importing the EDD into a structured document with "Remove Format Overrides" turned on will eliminate every single instance in which authors overrode the EDD-specified formatting. When authors realize this step is part of the review process, they know the jig is up. -
Reasons to Structure
--- Charles Beck wrote: > Besides-with the caveat that I have not actually > experienced *enforced* structured authoring, per > s?-if you need to format a word or phrase for > emphasis or for special recognition (such as bolding > UI elements), don't you still have to tag that > content somewhere? So where is the great advantage? === Semantic tagging of a word or phrase can be implemented by wrapping it with an EDD-defined text-range element whose element name describes the semantic type. A format rule in the EDD automatically applies the correct format to it. > As I understand structured authoring (with my > admittedly limited understanding), its strengths > seem to lie more in the realm of freeing the author > from having to make specific adhoc formatting > decisions that may or (more likely) may not be > consistent. That, and enforcing certain rules about > what content is required, accepted, optional, etc. === In a properly designed EDD, there is no such thing as ad-hoc formatting. That is, Format rules define all formatting. These format rules can be based on one or more of the following: element name, element context, element attribute value(s), and format change lists referenced from within the format rules. Typically, full use of these capabilities can drastically reduce the number of paragraph and character formats required in a FrameMaker template. I could go on to describe numerous other advantages of this approach to formatting. Typically, full use of
Reasons to Structure
On Wed, 14 Feb 2007 04:56:49 -0700, russ at weststreetconsulting.com wrote: >Jeremy Griffith wrote [referring to semantic markup]: > >>You can do the same with paragraph formats, too. But you can >>do all that in UNstructured docs just as easily as in structured. >>Maybe *more* easily, when you factor in the time to set up your >>structure, and to modify it when you make changes, which is major. >> >>I've only been able to identify one situation in which structured >>Frame can do this better than unstructured, and that's when you'd >>want nested element tags within a paragraph, since you cam't nest >>character formats. (There are easy workarounds for creating the >>equivalent of nested paragraph formats, such as using start/end >>formats and/or markers.) OTOH, I have yet to see a non-hypothetical >>case where such nested char formats were really needed... >> >>Structured Frame is designed for large pubs groups where standard >>document designs are required, perhaps for ISO 9000, perhaps for >>other corporate policy reasons. For smaller groups, and especially >>for lone writers, the setup costs (time and consultants) are likely >>to exceed the benefits, much like a CMS (Content Management System) >>can. There are excellent consultants around, many on this list, >>for whom it is a breeze. If you decide to go this way, hire one. >>It will prevent much anguish and hair loss. >This is misinformation, on nearly all counts. Isn't that a tad harsh, Russ? My point, which you appear to have missed, is that (as Richard said) semantic markup is good, *and* that you can do it in unstructured Frame. Do you deny this fact? I also said that for small groups, "the setup costs (time and consultants) are likely to exceed the benefits". I'll stand by that assessment, based on using Frame in both its unstructured *and* structured (formerly known as "FrameBuilder") forms over many, many years, originally on a Sun 2... I didn't say there are *no* benefits, just that the costs may be greater. Do you assert that the costs are always insignificant, then? >I am a lone writer who is completely dependent on structured Frame. >Without it, I would need at least twice the manpower to handle the >busywork that it does. Furthermore, I adhere to no industry standard >and make changes to my structured template frequently. All well and good... but what *else* are you? An expert in structure, perhaps? How long have you worked with structure? As I said, "There are excellent consultants around, many on this list, for whom it is a breeze." You are one of the four or five I'd think of first... Here's the first line on your home page: "Welcome to West Street Consulting, your home for structured FrameMaker? plugins and other utilities." I've also written plugins that work with structured Frame (Mif2Go does, just fine), but I hardly consider myself a representative Frame user... nor would I assume that everyone would have as easy a time as I do. Do you say it's easy for everyone? >Granted, the setup costs for me are minimal now, because I >have the skill set. My point exactly. That's why I said "hire a consultant". Do you think consultants are unnecessary? >But that is the whole point of these occasional rants... you >just have to get in there and learn, because that's when it >becomes a breeze. Assuming, that is, that you *have* the time. Many of our colleagues, having survived downsizing from ten writers to two with no decrease of workload, do not. And if you do, is that time better spent on learning nifty new tools, or on improving the docs you're paid to write? One size does *not* fit all. If you have a genuine *business* case for going to structured Frame (or if you are a hacker at heart, like you and I), go for it. ;-) >Of course it takes time to ramp up, but when it is so >obviously the way of the future, ... This makes me feel old.Well, I *am* old... old enough to remember any number of "obvious" advances that went nowhere. The future has many ways... most of which we won't recognize until we get there. Here's a little related snippet from [XML-DEV] today: > [Michael Chanpion:] On the other hand, this is more or less > the story of CORBA ? lots of time and money spent on something > that has vastly underperformed relative to its initial hype. > [Elliotte Rusty Harold:] Exactly, and that's hardly the only > example of lots of corporate money being fed into the shredder. That's in the current "More predictions to mull over" thread... >Two final points... > >- I'll retract much of what I said if you can provide a single >recent example of anything groundbreaking in the area of techcomm >that specifically involved unstructured content. The Web? You don't consider HTML an example of structured content, do you? It qualifies in only the most technical sense... and most pages violate even its simple DTDs grossly. Or maybe it's not recent enough for you? >- Always
RE: Reasons to Structure
Sorry to be so delinquent in responding to this; I have my excuses. Some of us actually LIKE the left-brain right-brain gear shifting and are quite efficient at it. Mind you, I am a great proponent of structured authoring in theory and a miserable practitioner. Maybe it is because I am blessed with a mind that is peculiarly both analytical and creative in more-or-less equal measure. Besides-with the caveat that I have not actually experienced *enforced* structured authoring, per sé-if you need to format a word or phrase for emphasis or for special recognition (such as bolding UI elements), don't you still have to tag that content somewhere? So where is the great advantage? As I understand structured authoring (with my admittedly limited understanding), its strengths seem to lie more in the realm of freeing the author from having to make specific adhoc formatting decisions that may or (more likely) may not be consistent. That, and enforcing certain rules about what content is required, accepted, optional, etc. Is it not so? Chuck Beck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Rickaby Sent: Monday, February 12, 2007 10:10 AM To: framers@FrameUsers.com Cc: MATT TODD Subject: Re: Reasons to Structure At 06:45 -0800 12/2/07, Rene Stephenson wrote: * Dynamic formatting: you can use structured FM to create formats that behave differently depending on various surrounding factors, like indent to a certain level if it follows X paragraph but to a different level if it follows Y paragraph. This is true, but is only part of [this part] of the story. You can, if you choose, construct an EDD that applies all formatting, using the context-sensitive features that Rene describes. To see what this can mean in terms of productivity, consider the actions an author performs when working with unstructured FrameMaker: . Write a bit (left brain, focus on content) . Go to paragraph catalog, apply a paragraph format (right brain, focus on presentation) . Write a bit more (left brain, focus on content) . Think about character markup-up, select a word (right brain, focus on presentation) . Go to character catalog, apply a character format (right brain, focus on presentation) . Write some more (left brain, focus on content) . Decide that you don't like the presentation (right brain), go mess with the Paragraph Designer, waste twenty minutes... Thus the author is constantly switching mental modalities and is constantly distracted from the job at hand: writing. Contrast this with using a structured document in which the EDD controls the formatting: . Select an element (mid-brain ;-) . Write (left brain) . Hit return: EDD controls next element (no brain ;-) . Write (left brain) and so on... with absolutely no trips to paragraph catalog or Paragraph Designer, ever. And this is only one of a great many advantages of structure: others will elaborate all the stuff about validation, round-tripping, single-sourcing, standards and so on. Forgive me if I've got left brain and right brain the wrong way around: I'm left-handed. -- Steve ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/charles.beck%40infor.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Reasons to Structure
The point is that you tag a UI element as a UI element because it is a UI element. You make it bold (or whatever) at a later point in the process based on how you choose to format the semantically tagged elements for a given deliverable. The element itself is tagged according to what kind of information it is, so the tagging is basically meta-information that has added value to your content because it can be used in all sorts of post-processing operations. Semantic tagging of in-line elements (like names of parameters and API functions) is so valuable that our pubs group was doing it in our Word documentation many before we transitioned to Frame, which was several years before we were acquired by Intel and even more years before Intel sold off that business unit and all those documents. My opinions only; I don't speak for Intel. Fred Ridder (fred dot ridder at intel dot com) Intel Parsippany, NJ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Beck Sent: Tuesday, February 13, 2007 11:16 PM To: Steve Rickaby; framers@FrameUsers.com Cc: MATT TODD Subject: RE: Reasons to Structure Sorry to be so delinquent in responding to this; I have my excuses. Some of us actually LIKE the left-brain right-brain gear shifting and are quite efficient at it. Mind you, I am a great proponent of structured authoring in theory and a miserable practitioner. Maybe it is because I am blessed with a mind that is peculiarly both analytical and creative in more-or-less equal measure. Besides-with the caveat that I have not actually experienced *enforced* structured authoring, per sé-if you need to format a word or phrase for emphasis or for special recognition (such as bolding UI elements), don't you still have to tag that content somewhere? So where is the great advantage? As I understand structured authoring (with my admittedly limited understanding), its strengths seem to lie more in the realm of freeing the author from having to make specific adhoc formatting decisions that may or (more likely) may not be consistent. That, and enforcing certain rules about what content is required, accepted, optional, etc. Is it not so? Chuck Beck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Rickaby Sent: Monday, February 12, 2007 10:10 AM To: framers@FrameUsers.com Cc: MATT TODD Subject: Re: Reasons to Structure At 06:45 -0800 12/2/07, Rene Stephenson wrote: * Dynamic formatting: you can use structured FM to create formats that behave differently depending on various surrounding factors, like indent to a certain level if it follows X paragraph but to a different level if it follows Y paragraph. This is true, but is only part of [this part] of the story. You can, if you choose, construct an EDD that applies all formatting, using the context-sensitive features that Rene describes. To see what this can mean in terms of productivity, consider the actions an author performs when working with unstructured FrameMaker: . Write a bit (left brain, focus on content) . Go to paragraph catalog, apply a paragraph format (right brain, focus on presentation) . Write a bit more (left brain, focus on content) . Think about character markup-up, select a word (right brain, focus on presentation) . Go to character catalog, apply a character format (right brain, focus on presentation) . Write some more (left brain, focus on content) . Decide that you don't like the presentation (right brain), go mess with the Paragraph Designer, waste twenty minutes... Thus the author is constantly switching mental modalities and is constantly distracted from the job at hand: writing. Contrast this with using a structured document in which the EDD controls the formatting: . Select an element (mid-brain ;-) . Write (left brain) . Hit return: EDD controls next element (no brain ;-) . Write (left brain) and so on... with absolutely no trips to paragraph catalog or Paragraph Designer, ever. And this is only one of a great many advantages of structure: others will elaborate all the stuff about validation, round-tripping, single-sourcing, standards and so on. Forgive me if I've got left brain and right brain the wrong way around: I'm left-handed. -- Steve ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/charles.beck%40infor.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options
Re: Reasons to Structure
On Tue, 13 Feb 2007 23:27:15 -0500, Ridder, Fred [EMAIL PROTECTED] wrote: The point is that you tag a UI element as a UI element because it is a UI element. You make it bold (or whatever) at a later point in the process based on how you choose to format the semantically tagged elements for a given deliverable. Excellent point! I totally agree, and use that for character formats at every opportunity. You wind up with more formats, many of which are specified identically, but that's a small price to pay. You can do the same with paragraph formats, too. But you can do all that in UNstructured docs just as easily as in structured. Maybe *more* easily, when you factor in the time to set up your structure, and to modify it when you make changes, which is major. I've only been able to identify one situation in which structured Frame can do this better than unstructured, and that's when you'd want nested element tags within a paragraph, since you cam't nest character formats. (There are easy workarounds for creating the equivalent of nested paragraph formats, such as using start/end formats and/or markers.) OTOH, I have yet to see a non-hypothetical case where such nested char formats were really needed... Structured Frame is designed for large pubs groups where standard document designs are required, perhaps for ISO 9000, perhaps for other corporate policy reasons. For smaller groups, and especially for lone writers, the setup costs (time and consultants) are likely to exceed the benefits, much like a CMS (Content Management System) can. There are excellent consultants around, many on this list, for whom it is a breeze. If you decide to go this way, hire one. It will prevent much anguish and hair loss. -- Jeremy H. Griffith, at Omni Systems Inc. [EMAIL PROTECTED] http://www.omsys.com/ ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Reasons to Structure
The point is that you tag a UI element as a UI element because it is a UI element. You make it bold (or whatever) at a later point in the process based on how you choose to format the semantically tagged elements for a given deliverable. The element itself is tagged according to what kind of information it is, so the tagging is basically meta-information that has added value to your content because it can be used in all sorts of post-processing operations. Semantic tagging of in-line elements (like names of parameters and API functions) is so valuable that our pubs group was doing it in our Word documentation many before we transitioned to Frame, which was several years before we were acquired by Intel and even more years before Intel sold off that business unit and all those documents. My opinions only; I don't speak for Intel. Fred Ridder (fred dot ridder at intel dot com) Intel Parsippany, NJ -Original Message- From: framers-bounces+fred.ridder=intel.com at lists.frameusers.com [mailto:framers-bounces+fred.ridder=intel@lists.frameusers.com] On Behalf Of Charles Beck Sent: Tuesday, February 13, 2007 11:16 PM To: Steve Rickaby; framers at FrameUsers.com Cc: MATT TODD Subject: RE: Reasons to Structure Sorry to be so delinquent in responding to this; I have my excuses. Some of us actually LIKE the left-brain right-brain gear shifting and are quite efficient at it. Mind you, I am a great proponent of structured authoring in theory and a miserable practitioner. Maybe it is because I am blessed with a mind that is peculiarly both analytical and creative in more-or-less equal measure. Besides-with the caveat that I have not actually experienced *enforced* structured authoring, per s?-if you need to format a word or phrase for emphasis or for special recognition (such as bolding UI elements), don't you still have to tag that content somewhere? So where is the great advantage? As I understand structured authoring (with my admittedly limited understanding), its strengths seem to lie more in the realm of freeing the author from having to make specific adhoc formatting decisions that may or (more likely) may not be consistent. That, and enforcing certain rules about what content is required, accepted, optional, etc. Is it not so? Chuck Beck -Original Message- From: framers-bounces+charles.beck=infor.com at lists.frameusers.com [mailto:framers-bounces+charles.beck=infor@lists.frameusers.com] On Behalf Of Steve Rickaby Sent: Monday, February 12, 2007 10:10 AM To: framers at FrameUsers.com Cc: MATT TODD Subject: Re: Reasons to Structure At 06:45 -0800 12/2/07, Rene Stephenson wrote: > * Dynamic formatting: you can use structured FM to create formats that > behave differently depending on various surrounding factors, like indent to a > certain level if it follows X paragraph but to a different level if it > follows Y paragraph. This is true, but is only part of [this part] of the story. You can, if you choose, construct an EDD that applies all formatting, using the context-sensitive features that Rene describes. To see what this can mean in terms of productivity, consider the actions an author performs when working with unstructured FrameMaker: . Write a bit (left brain, focus on content) . Go to paragraph catalog, apply a paragraph format (right brain, focus on presentation) . Write a bit more (left brain, focus on content) . Think about character markup-up, select a word (right brain, focus on presentation) . Go to character catalog, apply a character format (right brain, focus on presentation) . Write some more (left brain, focus on content) . Decide that you don't like the presentation (right brain), go mess with the Paragraph Designer, waste twenty minutes... Thus the author is constantly switching mental modalities and is constantly distracted from the job at hand: writing. Contrast this with using a structured document in which the EDD controls the formatting: . Select an element (mid-brain ;-) . Write (left brain) . Hit return: EDD controls next element (no brain ;-) . Write (left brain) and so on... with absolutely no trips to paragraph catalog or Paragraph Designer, ever. And this is only one of a great many advantages of structure: others will elaborate all the stuff about validation, round-tripping, single-sourcing, standards and so on. Forgive me if I've got left brain and right brain the wrong way around: I'm left-handed. -- Steve ___ You are currently subscribed to Framers as Charles.Beck at infor.com. Send list messages to framers at lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscribe at lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/charles.beck%40infor.com Send administrative questions to listadmin at frameusers.com. Visit http://www.frameusers.com/ for more resour
Reasons to Structure
On Tue, 13 Feb 2007 23:27:15 -0500, "Ridder, Fred" wrote: >The point is that you tag a UI element as a UI element because >it is a UI element. You make it bold (or whatever) at a later point >in the process based on how you choose to format the semantically >tagged elements for a given deliverable. Excellent point! I totally agree, and use that for character formats at every opportunity. You wind up with more formats, many of which are specified identically, but that's a small price to pay. You can do the same with paragraph formats, too. But you can do all that in UNstructured docs just as easily as in structured. Maybe *more* easily, when you factor in the time to set up your structure, and to modify it when you make changes, which is major. I've only been able to identify one situation in which structured Frame can do this better than unstructured, and that's when you'd want nested element tags within a paragraph, since you cam't nest character formats. (There are easy workarounds for creating the equivalent of nested paragraph formats, such as using start/end formats and/or markers.) OTOH, I have yet to see a non-hypothetical case where such nested char formats were really needed... Structured Frame is designed for large pubs groups where standard document designs are required, perhaps for ISO 9000, perhaps for other corporate policy reasons. For smaller groups, and especially for lone writers, the setup costs (time and consultants) are likely to exceed the benefits, much like a CMS (Content Management System) can. There are excellent consultants around, many on this list, for whom it is a breeze. If you decide to go this way, hire one. It will prevent much anguish and hair loss. -- Jeremy H. Griffith, at Omni Systems Inc. http://www.omsys.com/
Reasons to Structure
All right...tell me good, solid reasons why a company would want to structure their documents. With my limited knowledge, I know structure effectively controls styles, fonts, etc...but I could manage that myself without structure. By extension, I know style control also controls content location because particular types of writing usually use a particular style...but I can also manage that myself. I know structure is designed to encourage single-sourcing, but I'm already headed in that direction without structure. I'm convinced with time and continuing documentation analysis, I can parse our documentation so duplicate verbiage in all our documents imports from one source. I can do that without structure. I can use conditional text to further cut down duplicate verbiage; it requires no structure. I can buy scripts or third-party software to automate documentation procedures without resorting to structure. So tell me...why structure documentation? I don't know enough to answer that question, and neither do my bosses. What's so great about it? What capabilities does it offer that demand its use? Right now, I'm just doing what I'm told, but it's always nice to found actions on solid reason. Matt I'm working with legacy documentation created in Word and FM 7.0 unstructured. The goal is FM 7.0 structured. Whose goal is this, and why? I've seen the gee whiz demonstrations from Adobe reps and been utterly convinced that I Need Structured Docs Now! only to return to my pdf-output-only client projects that have no real need for structured Frame. Before committing, make sure there's a business case for structuring. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Reasons to Structure
Matt, I'll start the ball rolling, but I'm sure you'll get tons of responses from folks more savvy about structure than myself. ;-) * Dynamic formatting: you can use structured FM to create formats that behave differently depending on various surrounding factors, like indent to a certain level if it follows X paragraph but to a different level if it follows Y paragraph. * Ability to produce cleaner XML for flexible web output. Rene MATT TODD [EMAIL PROTECTED] wrote: All right...tell me good, solid reasons why a company would want to structure their documents. With my limited knowledge, I know structure effectively controls styles, fonts, etc...but I could manage that myself without structure. By extension, I know style control also controls content location because particular types of writing usually use a particular style...but I can also manage that myself. I know structure is designed to encourage single-sourcing, but I'm already headed in that direction without structure. I'm convinced with time and continuing documentation analysis, I can parse our documentation so duplicate verbiage in all our documents imports from one source. I can do that without structure. I can use conditional text to further cut down duplicate verbiage; it requires no structure. I can buy scripts or third-party software to automate documentation procedures without resorting to structure. So tell me...why structure documentation? I don't know enough to answer that question, and neither do my bosses. What's so great about it? What capabilities does it offer that demand its use? Right now, I'm just doing what I'm told, but it's always nice to found actions on solid reason. Matt I'm working with legacy documentation created in Word and FM 7.0 unstructured. The goal is FM 7.0 structured. Whose goal is this, and why? I've seen the gee whiz demonstrations from Adobe reps and been utterly convinced that I Need Structured Docs Now! only to return to my pdf-output-only client projects that have no real need for structured Frame. Before committing, make sure there's a business case for structuring. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/rinnie1%40yahoo.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info. Rene L. Stephenson eNovative Solutions, Inc. Business Phone: 678-513-0051 Email: [EMAIL PROTECTED] ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Reasons to Structure
I think it depends on what you're doing and with how many people. If you're all by yourself, and you only need PDF and one type of help output...I don't really think there is a reason to go to structured authoring. It's perfectly possible for you to handle all of it yourself. (I've been doing it for 4.5 years) If you're working with a group of writers, it's harder to enforce that X is always bold and Y is always phrased like so. Text insets become painful to manage. I think with structured authoring, it's easier to enforce a similar style across multiple authors. (i.e. If you don't manage your content as defined, you can't produce anything.) I also think if you're going to have multiple, similar outputs, structured authoring where you re-use bits becomes more important. Yes, you might be able to handle it with conditional text and text insets...but it can get crazy really fast. Cross-references do not play happily with conditional text and text insets in FrameMaker. I just left my position as a sole writer where I had everything under control with text insets and some conditional stuff and some framescripts. I really wanted to learn about XML and structured authoring...and I felt there was zero reason for me to attempt to switch in my situation. I had a method that worked. To move to structured authoring, I would have had to a) thrown out everything I had accomplished and b) taught myself without any hope of training a new, complex method. It wasn't worth my time or energy. I just started at a new position in a company that's moving from Unstructured Frame to an XML/Structured Authoring solution. Here, it makes sense that they're making the switch. Documents need to be standardized, XML is cheaper to translate than Frame Files (I think? That's the rumor I heard. I could be wrong. :-) Here, I'll have a bunch of other writers to work with as we make the switch, and, we're actually going to get training! (yay!) YMMV, Zoë We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265 ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Reasons to Structure
Structure gives you the benefit of separating content from presentation. Sounds trivial, and you may think you've accomplished this without structure, but that is the primary reason to structure content: so your XML abstraction is as agnostic as possible to the form of rendition that you will publish in. Typically, most unstructured forms of content management blur the distinction between the XML abstraction and the XML (or other) rendition. Structuring content using XML standards also enables interoperability with the ever-evolving publishing tools at our disposal. We don't really know what cool publishing application will come up next, but we can bet it will import and export XML, thus it will be interoperable with systems based on structured content. Not that structured content is always the right path... The sorts of question to ask are: * How many output formats do you have? (if it is just one, perhaps unstructured is best!) * Is translation required? (XML content management can definitely reduce cost of translation) * How much content reuse is required/implemented? (the more reuse, the more benefit structure provides) I would encourage you to explore the Adobe FrameMaker 7.2 Application Pack for DITA, in particular its Open Toolkit integration. I think when you generate different forms of help using the OT, combined with PDF using the Framemaker rendition engine, you will understand the benefits of structured content. http://www.adobe.com/go/dita/ Thanks, Max -- Max Dunn Silicon Publishing -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] om] On Behalf Of Rene Stephenson Sent: Monday, February 12, 2007 6:46 AM To: MATT TODD; framers@lists.frameusers.com Subject: Re: Reasons to Structure Matt, I'll start the ball rolling, but I'm sure you'll get tons of responses from folks more savvy about structure than myself. ;-) * Dynamic formatting: you can use structured FM to create formats that behave differently depending on various surrounding factors, like indent to a certain level if it follows X paragraph but to a different level if it follows Y paragraph. * Ability to produce cleaner XML for flexible web output. Rene MATT TODD [EMAIL PROTECTED] wrote: All right...tell me good, solid reasons why a company would want to structure their documents. With my limited knowledge, I know structure effectively controls styles, fonts, etc...but I could manage that myself without structure. By extension, I know style control also controls content location because particular types of writing usually use a particular style...but I can also manage that myself. I know structure is designed to encourage single-sourcing, but I'm already headed in that direction without structure. I'm convinced with time and continuing documentation analysis, I can parse our documentation so duplicate verbiage in all our documents imports from one source. I can do that without structure. I can use conditional text to further cut down duplicate verbiage; it requires no structure. I can buy scripts or third-party software to automate documentation procedures without resorting to structure. So tell me...why structure documentation? I don't know enough to answer that question, and neither do my bosses. What's so great about it? What capabilities does it offer that demand its use? Right now, I'm just doing what I'm told, but it's always nice to found actions on solid reason. Matt I'm working with legacy documentation created in Word and FM 7.0 unstructured. The goal is FM 7.0 structured. Whose goal is this, and why? I've seen the gee whiz demonstrations from Adobe reps and been utterly convinced that I Need Structured Docs Now! only to return to my pdf-output-only client projects that have no real need for structured Frame. Before committing, make sure there's a business case for structuring. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/rinnie1%40yahoo.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info. Rene L. Stephenson eNovative Solutions, Inc. Business Phone: 678-513-0051 Email: [EMAIL PROTECTED] ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/maxdunn%40siliconpub lishing.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info. IMPORTANT NOTICE: This communication, including any attachment, contains information that may be confidential or privileged, and is intended solely for the entity
Re: Reasons to Structure
At 06:45 -0800 12/2/07, Rene Stephenson wrote: * Dynamic formatting: you can use structured FM to create formats that behave differently depending on various surrounding factors, like indent to a certain level if it follows X paragraph but to a different level if it follows Y paragraph. This is true, but is only part of [this part] of the story. You can, if you choose, construct an EDD that applies all formatting, using the context-sensitive features that Rene describes. To see what this can mean in terms of productivity, consider the actions an author performs when working with unstructured FrameMaker: . Write a bit (left brain, focus on content) . Go to paragraph catalog, apply a paragraph format (right brain, focus on presentation) . Write a bit more (left brain, focus on content) . Think about character markup-up, select a word (right brain, focus on presentation) . Go to character catalog, apply a character format (right brain, focus on presentation) . Write some more (left brain, focus on content) . Decide that you don't like the presentation (right brain), go mess with the Paragraph Designer, waste twenty minutes... Thus the author is constantly switching mental modalities and is constantly distracted from the job at hand: writing. Contrast this with using a structured document in which the EDD controls the formatting: . Select an element (mid-brain ;-) . Write (left brain) . Hit return: EDD controls next element (no brain ;-) . Write (left brain) and so on... with absolutely no trips to paragraph catalog or Paragraph Designer, ever. And this is only one of a great many advantages of structure: others will elaborate all the stuff about validation, round-tripping, single-sourcing, standards and so on. Forgive me if I've got left brain and right brain the wrong way around: I'm left-handed. -- Steve ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Reasons to Structure
All right...tell me good, solid reasons why a company would want to structure their documents. With my limited knowledge, I know structure effectively controls styles, fonts, etc...but I could manage that myself without structure. By extension, I know style control also controls content location because particular types of writing usually use a particular style...but I can also manage that myself. I know structure is designed to encourage single-sourcing, but I'm already headed in that direction without structure. I'm convinced with time and continuing documentation analysis, I can parse our documentation so duplicate verbiage in all our documents imports from one source. I can do that without structure. I can use conditional text to further cut down duplicate verbiage; it requires no structure. I can buy scripts or third-party software to automate documentation procedures without resorting to structure. So tell me...why structure documentation? I don't know enough to answer that question, and neither do my bosses. What's so great about it? What capabilities does it offer that demand its use? Right now, I'm just doing what I'm told, but it's always nice to found actions on solid reason. Matt > I'm working with legacy documentation created in Word and FM 7.0 > unstructured. The goal is FM 7.0 structured. Whose goal is this, and why? I've seen the gee whiz demonstrations from Adobe reps and been utterly convinced that I Need Structured Docs Now! only to return to my pdf-output-only client projects that have no real need for structured Frame. Before committing, make sure there's a business case for structuring.
Reasons to Structure
Matt, I'll start the ball rolling, but I'm sure you'll get tons of responses from folks more savvy about structure than myself. ;-) * Dynamic formatting: you can use structured FM to create formats that behave differently depending on various surrounding factors, like indent to a certain level if it follows X paragraph but to a different level if it follows Y paragraph. * Ability to produce cleaner XML for flexible web output. Rene MATT TODD wrote: All right...tell me good, solid reasons why a company would want to structure their documents. With my limited knowledge, I know structure effectively controls styles, fonts, etc...but I could manage that myself without structure. By extension, I know style control also controls content location because particular types of writing usually use a particular style...but I can also manage that myself. I know structure is designed to encourage single-sourcing, but I'm already headed in that direction without structure. I'm convinced with time and continuing documentation analysis, I can parse our documentation so duplicate verbiage in all our documents imports from one source. I can do that without structure. I can use conditional text to further cut down duplicate verbiage; it requires no structure. I can buy scripts or third-party software to automate documentation procedures without resorting to structure. So tell me...why structure documentation? I don't know enough to answer that question, and neither do my bosses. What's so great about it? What capabilities does it offer that demand its use? Right now, I'm just doing what I'm told, but it's always nice to found actions on solid reason. Matt > I'm working with legacy documentation created in Word and FM 7.0 > unstructured. The goal is FM 7.0 structured. Whose goal is this, and why? I've seen the gee whiz demonstrations from Adobe reps and been utterly convinced that I Need Structured Docs Now! only to return to my pdf-output-only client projects that have no real need for structured Frame. Before committing, make sure there's a business case for structuring. ___ You are currently subscribed to Framers as rinnie1 at yahoo.com. Send list messages to framers at lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscribe at lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/rinnie1%40yahoo.com Send administrative questions to listadmin at frameusers.com. Visit http://www.frameusers.com/ for more resources and info. Rene L. Stephenson eNovative Solutions, Inc. Business Phone: 678-513-0051 Email: rinnie1 at yahoo.com
Reasons to Structure
I think it depends on what you're doing and with how many people. If you're all by yourself, and you only need PDF and one type of help output...I don't really think there is a reason to go to structured authoring. It's perfectly possible for you to handle all of it yourself. (I've been doing it for 4.5 years) If you're working with a group of writers, it's harder to enforce that X is always bold and Y is always phrased like so. Text insets become painful to manage. I think with structured authoring, it's easier to enforce a similar style across multiple authors. (i.e. If you don't manage your content as defined, you can't produce anything.) I also think if you're going to have multiple, similar outputs, structured authoring where you re-use bits becomes more important. Yes, you might be able to handle it with conditional text and text insets...but it can get crazy really fast. Cross-references do not play happily with conditional text and text insets in FrameMaker. I just left my position as a sole writer where I had everything under control with text insets and some conditional stuff and some framescripts. I really wanted to learn about XML and structured authoring...and I felt there was zero reason for me to attempt to switch in my situation. I had a method that worked. To move to structured authoring, I would have had to a) thrown out everything I had accomplished and b) taught myself without any hope of training a new, complex method. It wasn't worth my time or energy. I just started at a new position in a company that's moving from Unstructured Frame to an XML/Structured Authoring solution. Here, it makes sense that they're making the switch. Documents need to be standardized, XML is cheaper to translate than Frame Files (I think? That's the rumor I heard. I could be wrong. :-) Here, I'll have a bunch of other writers to work with as we make the switch, and, we're actually going to get training! (yay!) YMMV, Zo? We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265
Reasons to Structure
Structure gives you the benefit of separating content from presentation. Sounds trivial, and you may think you've accomplished this without structure, but that is the primary reason to structure content: so your XML abstraction is as agnostic as possible to the form of rendition that you will publish in. Typically, most unstructured forms of content management blur the distinction between the XML abstraction and the XML (or other) rendition. Structuring content using XML standards also enables interoperability with the ever-evolving publishing tools at our disposal. We don't really know what cool publishing application will come up next, but we can bet it will import and export XML, thus it will be interoperable with systems based on structured content. Not that structured content is always the right path... The sorts of question to ask are: * How many output formats do you have? (if it is just one, perhaps unstructured is best!) * Is translation required? (XML content management can definitely reduce cost of translation) * How much content reuse is required/implemented? (the more reuse, the more benefit structure provides) I would encourage you to explore the Adobe FrameMaker 7.2 Application Pack for DITA, in particular its Open Toolkit integration. I think when you generate different forms of help using the OT, combined with PDF using the Framemaker rendition engine, you will understand the benefits of structured content. http://www.adobe.com/go/dita/ Thanks, Max -- Max Dunn Silicon Publishing -Original Message- From: framers-bounces+maxdunn=siliconpublishing@lists.frameusers.com [mailto:framers-bounces+maxdunn=siliconpublishing.com at lists.frameusers.c om] On Behalf Of Rene Stephenson Sent: Monday, February 12, 2007 6:46 AM To: MATT TODD; framers at lists.frameusers.com Subject: Re: Reasons to Structure Matt, I'll start the ball rolling, but I'm sure you'll get tons of responses from folks more savvy about structure than myself. ;-) * Dynamic formatting: you can use structured FM to create formats that behave differently depending on various surrounding factors, like indent to a certain level if it follows X paragraph but to a different level if it follows Y paragraph. * Ability to produce cleaner XML for flexible web output. Rene MATT TODD wrote: All right...tell me good, solid reasons why a company would want to structure their documents. With my limited knowledge, I know structure effectively controls styles, fonts, etc...but I could manage that myself without structure. By extension, I know style control also controls content location because particular types of writing usually use a particular style...but I can also manage that myself. I know structure is designed to encourage single-sourcing, but I'm already headed in that direction without structure. I'm convinced with time and continuing documentation analysis, I can parse our documentation so duplicate verbiage in all our documents imports from one source. I can do that without structure. I can use conditional text to further cut down duplicate verbiage; it requires no structure. I can buy scripts or third-party software to automate documentation procedures without resorting to structure. So tell me...why structure documentation? I don't know enough to answer that question, and neither do my bosses. What's so great about it? What capabilities does it offer that demand its use? Right now, I'm just doing what I'm told, but it's always nice to found actions on solid reason. Matt > I'm working with legacy documentation created in Word and FM 7.0 > unstructured. The goal is FM 7.0 structured. Whose goal is this, and why? I've seen the gee whiz demonstrations from Adobe reps and been utterly convinced that I Need Structured Docs Now! only to return to my pdf-output-only client projects that have no real need for structured Frame. Before committing, make sure there's a business case for structuring. ___ You are currently subscribed to Framers as rinnie1 at yahoo.com. Send list messages to framers at lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscribe at lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/rinnie1%40yahoo.com Send administrative questions to listadmin at frameusers.com. Visit http://www.frameusers.com/ for more resources and info. Rene L. Stephenson eNovative Solutions, Inc. Business Phone: 678-513-0051 Email: rinnie1 at yahoo.com ___ You are currently subscribed to Framers as maxdunn at siliconpublishing.com. Send list messages to framers at lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscribe at lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/maxdunn%40siliconpub lishing.com Send administrative questions to listadmin at frameusers.com. Visit http://www.frameuse
Reasons to Structure
At 06:45 -0800 12/2/07, Rene Stephenson wrote: > * Dynamic formatting: you can use structured FM to create formats that > behave differently depending on various surrounding factors, like indent to a > certain level if it follows X paragraph but to a different level if it > follows Y paragraph. This is true, but is only part of [this part] of the story. You can, if you choose, construct an EDD that applies all formatting, using the context-sensitive features that Rene describes. To see what this can mean in terms of productivity, consider the actions an author performs when working with unstructured FrameMaker: . Write a bit (left brain, focus on content) . Go to paragraph catalog, apply a paragraph format (right brain, focus on presentation) . Write a bit more (left brain, focus on content) . Think about character markup-up, select a word (right brain, focus on presentation) . Go to character catalog, apply a character format (right brain, focus on presentation) . Write some more (left brain, focus on content) . Decide that you don't like the presentation (right brain), go mess with the Paragraph Designer, waste twenty minutes... Thus the author is constantly switching mental modalities and is constantly distracted from the job at hand: writing. Contrast this with using a structured document in which the EDD controls the formatting: . Select an element (mid-brain ;-) . Write (left brain) . Hit return: EDD controls next element (no brain ;-) . Write (left brain) and so on... with absolutely no trips to paragraph catalog or Paragraph Designer, ever. And this is only one of a great many advantages of structure: others will elaborate all the stuff about validation, round-tripping, single-sourcing, standards and so on. Forgive me if I've got left brain and right brain the wrong way around: I'm left-handed. -- Steve
