Structured versus Unstructured FrameMaker

[adrianaharper]

Hi everyone. I'm not sure if this is the right venue for this, so apologies if it's not, but I'm looking for information and opinion.

I'm working in TCS2, Windows 7 64 bit. I have been for about two years now, and I author in unstructured FrameMaker, import into RoboHelp and create online help. And at first, I wasn't doing much with conditional text in Frame, it was pretty straightforward authoring and so I began in unstructured Frame. I am now handling up to seven different conditional tags and various combinations therein... And someone mentioned to me that it could be a good idea to now move to structured Frame.

My main book consists of a TOC, index, and then several chapter files which are imported into the book. Each file is also part of it's own separate book, as I do generate PDFs as a secondary help type. I use bulleted lists, various heading levels, character tags and paragraph tags, and cross-references. I'm not sure what else is relevant information that impacts this move or that would serve as additional pro/con here.

I understand this would involve learning and time... So I need to be convinced of the value of moving to structured Frame, and then I need to convince others around me, etc. I'm wondering what the main advantages are, where the pain might be, if there are limitations when dealing with a Robohelp integration (if anyone knows that), etc. We are a small-ish company but I am the only writer, so I expect the help will only grow as we move forward.

Any thoughts/comments/details are appreciated.

Thanks,

Adriana

[Jeff_Coatsworth]

What do you think you'll gain by moving to structured FM? Unless you implement some sort of schema like DITA and a CMS for content re-use, it's probably not going to get you very far ahead.

[RoboColum_n_]

To add to what Jeff said, you may want to read this article on the WritersUA site. It is a little old but it still applies. Hopefully it will help you make up your mind.

---

The RoboColum(n)

@robocolumn

Colum McAndrew

[adrianaharper]

To be honest, I'm not 100% sure. I don't know enough about it. I had heard rumblings that structured Frame was way better at handling conditional text coding situations, especially multiple such situations, so in the immediate term, that was my biggest hope for a win?

[Michael_Müller-Hillebrand]

Adriana,

Regarding the conditional text topic it is correct what you heard. The combination of automatically applied layout through the EDD and attribute-based filtering using FrameMaker’s own feature or the far more flexible (free) solution AXCM by WestStreet Consulting results in a very good reliability if your task is to produce multiple documents from a master source.

I would recommend you get AXCM as it comes with sample files and a tutorial. Work through the tutorial and this should give you an idea how that stuff works and whether it applies to your situation.

http://www.weststreetconsulting.com/WSC_AXCM.htm

- Michael

[Russ Ward]

Jeff,

With all due respect, I think you are completely wrong. Even if you never venture into higher-end technologies related to structure, the simple move to the structured interface will save you untold amounts of time through increases in authoring efficiency. It is a vastly superior environment that allows you to automate so much of what used to be routine busywork, especially as related to formatting tasks. It amazes me that Adobe never promotes this side of the structured environment and that so many FrameMaker users are content to ignore such important features sitting right in front of them.

It is a reigning misconception that structured FM equals DITA or something like that, which is untrue. In fact, it might be that a majority of users would be better served by using structured FM without DITA. DITA is a very complex architecture that has its place, but that place is not everywhere. You might hear implications about how technical authoring as a whole is undergoing a "paradigm shift" towards DITA and/or DITA-like concepts, but don't buy it... DITA might be right for you, but then again it might not.

What is true, however, that all modern content management techniques rely on some nature of structure (that is, embedded "intelligence"), such that advanced processes can navigate the content and perform the required tasks. These techniques can be as simple as some little script a user writes, up to the functionality of a full-featured CMS. The key is structure... without it, your content is largely just words on the page that a computer can't efficiently navigate.

I'll am fond of saying this... if you use unstructured content, you are using technology that is decades old. In the tech world, that length of time effectively puts you back into the stone ages. The move to structured content will not only bring you closer to the present, it will position you for continued movement into the future.

I hope that I haven't been to abrasive and/or off-topic here... my intent really is to help us as a community, not to cause confrontation. It alarms me that so few technical communicators are embracing these new technologies, because I think it harms our profession as a whole. If we fail to keep up with the advancements that allow us to add value through increased efficiency, I'm concerned that the overall perceived value of the technical writer will diminish. That would bode ill for all of us in the field.

Russ

[Van Kurtz]

Adriana,

In my opinion, whatever flows from Russ Ward's lips is gospel. Structured writing is so much easier than unstructured. At the very least, it helps to insure consistency across your document set.

Furthermore, I second Michael's praise for AXCM. Since I have converted my conditioning to attributes, I have never had a FrameMaker crash when using AXCM to filter my documents. With FrameMakers native conditional text, crashes occurred weekly if not daily.

Van

[peter minneapolis]

Russ Ward wrote:

Jeff,

With all due respect, I think you are completely wrong. Even if you never venture into higher-end technologies related to structure, the simple move to the structured interface will save you untold amounts of time through increases in authoring efficiency. It is a vastly superior environment that allows you to automate so much of what used to be routine busywork, especially as related to formatting tasks. It amazes me that Adobe never promotes this side of the structured environment and that so many FrameMaker users are content to ignore such important features sitting right in front of them.

It is a reigning misconception that structured FM equals DITA or something like that, which is untrue. In fact, it might be that a majority of users would be better served by using structured FM without DITA. DITA is a very complex architecture that has its place, but that place is not everywhere. You might hear implications about how technical authoring as a whole is undergoing a "paradigm shift" towards DITA and/or DITA-like concepts, but don't buy it... DITA might be right for you, but then again it might not.

What is true, however, that all modern content management techniques rely on some nature of structure (that is, embedded "intelligence"), such that advanced processes can navigate the content and perform the required tasks. These techniques can be as simple as some little script a user writes, up to the functionality of a full-featured CMS. The key is structure... without it, your content is largely just words on the page that a computer can't efficiently navigate.

I'll am fond of saying this... if you use unstructured content, you are using technology that is decades old. In the tech world, that length of time effectively puts you back into the stone ages. The move to structured content will not only bring you closer to the present, it will position you for continued movement into the future.

I hope that I haven't been to abrasive and/or off-topic here... my intent really is to help us as a community, not to cause confrontation. It alarms me that so few technical communicators are embracing these new technologies, because I think it harms our profession as a whole. If we fail to keep up with the advancements that allow us to add value through increased efficiency, I'm concerned that the overall perceived value of the technical writer will diminish. That would bode ill for all of us in the field.

Russ

Hi, Russ:

Also, with due respect, I think you missed a key counter-argument against using structured FrameMaker, which is the investment required to create the EDD, the rules that define structure's intelligence (how you want it to behave to give you the efficency,) and also the enforcer of structure's rules. In addition, considering the difficulty of getting writers to accept the requirement of formatting with paragraph and character tags (IOW, no overrides,) it's not a simple matter to get them to learn to use the structured application that's given to them.

While these do not negate structured FrameMaker's pro's, they should be voiced so that potential adopters have a full picture to guide their decision.

HTH

Regards,

Peter

_______________________

Peter Gold

KnowHow ProServices

[Van Kurtz]

Peter Gold wrote:

Hi, Russ:

Also, with due respect, I think you missed a key counter-argument against using structured FrameMaker, which is the investment required to create the EDD, the rules that define structure's intelligence (how you want it to behave to give you the efficency,) and also the enforcer of structure's rules. In addition, considering the difficulty of getting writers to accept the requirement of formatting with paragraph and character tags (IOW, no overrides,) it's not a simple matter to get them to learn to use the structured application that's given to them.

Creating an EDD is just plain fun...an investment of love.

In Adriana's case (the original poster), she is the only writer. So, she should have not difficulty forcing herself to do what she wants. Learning how to insert elements and set attributes is a lot easier than trying to remember which paragraph tag to apply and when. A good EDD does this all for you.

In my opinion, there should be no paragraph and character tags, except the ones used by generated files. I created my EDD to apply all the formats directly, not by applying paragraph and character formats. This keeps these things away from writers prone to change tags. To those who feel this is taking freedom away from the writer, let me state that I did this to maintain consistency across our document set.

Van

[Jeff_Coatsworth]

Hmm, as a single writer too, I find that finding the time to invest in learning something new means that other work just piles up.

My original intention in responding to Adriana was to point out that it's not as simple as just throwing the switch in FM from unstructured to structured - there's a bit more work involved (DITA or not). Would-be structured author beware ;>)

[Russ Ward]

Great discussion. I haven't been involved in one of these for some time and I forgot how much I miss it.

Peter, all good points. My belief is that there is a rich payoff on the investment if you take the time to do it right. Anything that is new will require some investment, which in this case is EDDs, etc., but certainly it is proper to mention it. As far as resistant writers go, I would say that this is not so much a structured FM issue as it is an HR issue. It is silly to have people working in the field of technology who resist and/or struggle to understand technology. For any company that employs folks like that, the structured vs. unstructured FM argument is the least of its problems.

Van, nice words, thanks, but they embarrass me just a little. I have been wrong about lots of things and will continue to err in the future. I am reasonably positive, though, that technology will move forward, with or without you. Older technology equals less efficiency, and less efficiency will eventually equal a pink slip, off-shoring, some kind of commensurate pay cut, etc.  When a field of professionals is associated with that mode of operation, it is detrimental to all of us. I don't want us to be that way. I want technical writers to be at the forefront of adding value, rather than dragging on the bottom line out of stubbornness and/or ignorance. The only way for us to do that is to move with technology. So I preach on.

Russ

[Michael_Müller-Hillebrand]

Hi,

I would like to through some thoughts, that in 2003 (or so) basically got me involved with my first structured project:

• New writers should be productive as fast as possible

• New writers should make as little mistakes as possible

If you read "new writers" also think of interns or SMEs. How long does it take until they understand your paragraph/character catalog and your self-imposed rules how to use it?

If you read "mistakes", think of consistency or process issues, like "does the document pass the translation process without having to invest major amounts of time to fix everything in every language".

It is easier to teach/learn a well-build EDD and it is easy to control the technical quality.

- Michael

[peter minneapolis]

Van Kurtz wrote:

Peter Gold wrote:

Hi, Russ:

Also, with due respect, I think you missed a key counter-argument against using structured FrameMaker, which is the investment required to create the EDD, the rules that define structure's intelligence (how you want it to behave to give you the efficency,) and also the enforcer of structure's rules. In addition, considering the difficulty of getting writers to accept the requirement of formatting with paragraph and character tags (IOW, no overrides,) it's not a simple matter to get them to learn to use the structured application that's given to them.

Creating an EDD is just plain fun...an investment of love.

In Adriana's case (the original poster), she is the only writer. So, she should have not difficulty forcing herself to do what she wants. Learning how to insert elements and set attributes is a lot easier than trying to remember which paragraph tag to apply and when. A good EDD does this all for you.

In my opinion, there should be no paragraph and character tags, except the ones used by generated files. I created my EDD to apply all the formats directly, not by applying paragraph and character formats. This keeps these things away from writers prone to change tags. To those who feel this is taking freedom away from the writer, let me state that I did this to maintain consistency across our document set.

Van

It may be fun for you, Van, but for newcomers, creating an EDD of any degree of complexity is hard work, even with whatever training materials are available. I've taught structured FrameMaker courses - Introduction, for new users working in an established workflow, and Intermediate - developing an EDD (a FrameMaker element definition document, akin to an XML DTD.) I used the official training materials developed by Frame Technology (creators of FrameMaker) and rebranded as Adobe, with no changes. I still consider myself a beginner in many respects, perhaps because as a trainer I don't get the same rich experience that daily users - authors and EDD developers - benefit from.

Just trying to adapt an existing EDD to one's specific needs is a non-trivial task; developing one from scratch is hard work. It's programming, no matter how it's dressed up; it requires creating some code and then testing and then reiterating. The odds on a single writer with a full plate of work can't easily take on learning to create, then use, an EDD, approaching burn-out are pretty high, IMO.

HTH

Regards,

Peter

_______________________

Peter Gold

KnowHow ProServices

[adrianaharper]

This is exactly the type of discussion and information I was hoping to gather, and I hope it continues... Thank you to all who have contributed so far, so much good information.

Is there a way to determine if I (an organization) needs or would benefit from structured authoring over unstructured authoring? The ones I've found so far are:

·  You need to create  XML but want to work in a familiar authoring environment without dealing with  the minutiae of XML syntax.

·  You need to  enforce a consistent structure within and across documents.

·  You need a guided  editing interface to support authors in creating valid structured and/or XML  documents.

·  You need to create  valid XML documents because of your publishing requirements, customer  requirements, or content management needs.

·  You need to  publish print or PDF documents from XML source files.

(I found these items on the WritersUSA site as previously mentioned in this thread (thank you) - http://www.writersua.com/articles/frame/index.html)

I would say only one applies to me, at present - the consistent structure. That is always important. So if that is it, and I'm already doing that because I'm the only writer so I manage what I do on a daily basis, do I not need structured authoring?

I understand it would take time to learn, etc. and that is a real consideration. However, if that time equals a payoff in terms of my authoring, my generated end results, etc - it would be worth it in the long run. I guess in other words, I am open to short-term pain for long-term gain...On the other hand, I also need to explain to those around me why this needs to happen, so I need some arguments or backup for a change (other than moving ahead with technology - which is a good argument and one I agree with, but it doesn't necessarily justify the 'why' in terms of slowed production output in the interim, if it turns out the move isn't worth it...).

Thanks for the continued discussion and information,
Adriana

[Van Kurtz]

Adriana,

Maybe the extra time it takes to create the EDD, etc, could be balanced by the time wasted in fixing and recovering from frequent FrameMaker crashes due to problems with conditional text.

Van

[Russ Ward]

adrianaharper wrote:

I would say only one applies to me, at present - the consistent structure. That is always important. So if that is it, and I'm already doing that because I'm the only writer so I manage what I do on a daily basis, do I not need structured authoring?

Adriana, the point is that structured FM will make you more efficient at things you normally do, such as maintenance of consistent structure. You can maintain consistent structure with a typewriter, but I think you would acknowledge that such technology is no longer the model of efficiency. This comparison is adaptable to unstructured vs. structured FM. With structured FM, many formatting tasks are automated, such that you spend more time creating content rather than spending time on format. The examples are numerous... for example, numbered lists. A numbered list always starts at one. Always, right? With structured Frame, the logic built into the structure definition (EDD) enforces this rule, without you even thinking about it. All you have to do is indicate that a paragraph is a list item. With unstructured Frame, you generally have to 1) indicate that a paragraph is a list item and, 2) decide whether it is the first item or not. If you ever have to move items around, you may need to reevaluate all of this again.

This may seem like a minor detail that involves a tiny amount of time, but if you generate content at any quantity, it adds up. Combine this with the myriad of other little timesavers and you end up with hours saved over the months and years. I know this to be true. I am a lone writer with a very heavy workload that used to have several writers handling it. Were it not for the cumulative efficiencies provided by structured Frame, I would be doomed. With the help of efficiencies, however, I am producing a level of output that causes management to think I am some kind of workaholic wizard. The real magic is that while they think that, I am logging a smooth 40 hours a week and then leaning on technology to make it look like I am pure dedication. Now admittedly, structured FM alone won't let you assume a double workload, but it really can make a difference. I have lots of other tools and processes in place, but the authoring environment of structured FM is positively integral and irreplaceable.

To close, let me leave you with a tidbit of philosophy, going back to numbered lists... If something on a computer should always happen the same way every time, does it make any sense not to automate it? Isn't that what a computer is made for? If a computer can direct a spaceship through outer space and win on Jeopardy, don't you think it should at least be able to start numbered lists at "1" for you automatically? Just out of principle, I'd feel a bit ripped off if not.

Russ

[peter minneapolis]

Russ Ward wrote:

adrianaharper wrote:

I would say only one applies to me, at present - the consistent structure. That is always important. So if that is it, and I'm already doing that because I'm the only writer so I manage what I do on a daily basis, do I not need structured authoring?

Adriana, the point is that structured FM will make you more efficient at things you normally do, such as maintenance of consistent structure. You can maintain consistent structure with a typewriter, but I think you would acknowledge that such technology is no longer the model of efficiency. This comparison is adaptable to unstructured vs. structured FM. With structured FM, many formatting tasks are automated, such that you spend more time creating content rather than spending time on format. The examples are numerous... for example, numbered lists. A numbered list always starts at one. Always, right? With structured Frame, the logic built into the structure definition (EDD) enforces this rule, without you even thinking about it. All you have to do is indicate that a paragraph is a list item. With unstructured Frame, you generally have to 1) indicate that a paragraph is a list item and, 2) decide whether it is the first item or not. If you ever have to move items around, you may need to reevaluate all of this again.

This may seem like a minor detail that involves a tiny amount of time, but if you generate content at any quantity, it adds up. Combine this with the myriad of other little timesavers and you end up with hours saved over the months and years. I know this to be true. I am a lone writer with a very heavy workload that used to have several writers handling it. Were it not for the cumulative efficiencies provided by structured Frame, I would be doomed. With the help of efficiencies, however, I am producing a level of output that causes management to think I am some kind of workaholic wizard. The real magic is that while they think that, I am logging a smooth 40 hours a week and then leaning on technology to make it look like I am pure dedication. Now admittedly, structured FM alone won't let you assume a double workload, but it really can make a difference. I have lots of other tools and processes in place, but the authoring environment of structured FM is positively integral and irreplaceable.

To close, let me leave you with a tidbit of philosophy, going back to numbered lists... If something on a computer should always happen the same way every time, does it make any sense not to automate it? Isn't that what a computer is made for? If a computer can direct a spaceship through outer space and win on Jeopardy, don't you think it should at least be able to start numbered lists at "1" for you automatically? Just out of principle, I'd feel a bit ripped off if not.

Russ

Adriana, IMO, the answer is "yes" you don't need structured authoring. Now. But, if the writing team grows, it could be useful in helping achieve consistency with multiple authors, if the team players accept learning to use it, and an EDD is created that suits the writing projects. NOTE: There are folks who develop EDDs, so this ability can be hired.

It's obvious that Russ can't "not advocate" structured FrameMaker over unstructured FrameMaker at almost every opportunity where it could be considered an efficiency booster. Russ is right about the benefits of structured FrameMaker. No doubt about it.

It's also obvious that I can't "not advocate" the opposite, where the effort to develop a structured FrameMaker solution may outweigh the efficiency gain, or where the effort would consume limited resources that must be primarily dedicated to the current work load.

However, there are some features in unstructured FrameMaker that can improve efficiency with less effort than moving to structured FrameMaker.

Personally, my favorite feature of structured FrameMaker is its intelligent management of lists. So we're together on this. You can create rules in structured FrameMaker that tests list items to determine the first, the last, and the notfirst and notlast, and apply formatting. For example if you specify that the first list item has additional space above, the last list item has additional space below, and middle items have no extra space above and below, no matter how you change the position of list items, structured FrameMaker applies the rules and the formatting happens automatically. If it's a numbered list, there's a difference from unstructured FrameMaker; the autonumbers also follow your autonumbering rules for first, last, and notfirst, just as they do for space above and below first and last items.

In unstructured FrameMaker, three paragraph formats are required to manage a numbered list. The usual way to implement this is somewhat inefficient: setting the first list item to a paragraph format with extra space above, the following list items to a format that increment by one, and a format for the last list item to apply extra space below, requires the author to retag paragraphs if they are rearranged. Automating list formatting still requires three paragraph formats, but applied with a different strategy. Precede a numbered list with an introductory paragraph format that sets the number to zero and does not display it, by using this counter < =0> (NOTE there's a space between the left angle bracket and the equal sign.)  Also, specify the introductory paragraph to use space below. Format all numbered list items with the incrementing counter, <n+>. Define a format for the  paragraph that follows a list to have space above. Finally, you can specify that the list-introducing paragraph makes the next paragraph created with Enter/Return a list-item paragraph, that list-item paragraphs' next paragraph setting is the default same format, and the after-list paragraph makes its following paragraph body or whatever you like.

So, yes, Russ is correct that the unstructured author has to pay more attention to formatting than the structured author, but in some cases, efficiency can be improved by rethinking the use of unstructured FrameMaker's abilities.

You can get an idea of the effort involved to develop an EDD, learn to use it while authoring, and migrate your unstructured content to structured, by simply starting a thread whose subject is something like "Survey for unstructured FrameMaker users who have migrated to structured FrameMaker," and provide a link to a free online survey site like surveymonkey.com, where you've set up some questions.

HTH

Regards,

Peter

_______________________

Peter Gold

KnowHow ProServices

[Michael_Müller-Hillebrand]

Am 25.03.2011 um 16:45 schrieb peter at knowhowpro:

So, yes, Russ is correct that the unstructured author has to pay more attention to formatting than the structured author, but in some cases, efficiency can be improved by rethinking the use of unstructured FrameMaker's abilities.

An author who is accustomed to format-based authoring ('unstructured' is definitely the wrong term, isn’t it?) spends a certain percentage of his/her mind power to think about the formatting rules.

An author working in a well-designed structured (or: XML-based) environment does not think about formatting at all.

The key is "well-designed". As much as a bad template hurts your workflow an EDD that is not fit for the task stops you from reaching efficiency goals.

I think it is still worth reading a dialog from 2003 between David Knopf and John Frazzini, that I conserved under the self-invented title "What is Better: Wielding Stick or XML?":

http://cap-studio.de/wp/index.php/2003/10/what-is-better-wielding-stick-or-xml/

- Michael

[bowen192]

Russ,

Your posting on here facinates me.

I have downloaded AXCM for me to try this weekend (yes, I am that sad ).

I've just had a quick look at it and I can't see what advantage it has over creating an EDD yourself?  Does it have the facility to import styles, formats, master pages etc from a non-structured document?

I think I'm missing what it actually is that AXCM does

[Michael_Müller-Hillebrand]

Am 25.03.2011 um 16:52 schrieb bowen192:

I've just had a quick look at it and I can't see what advantage it has over creating an EDD yourself? Does it have the facility to import styles, formats, master pages etc from a non-structured document?

I think I'm missing what it actually is that AXCM does

You do. You need to have structured documents to take advantage of AXCM. Take the time to work through the tutorial with the supplied (structured) sample documents, this will give you a better idea of what this is all about.

- Michael

[bowen192]

Michael Müller-Hillebrand wrote:

You do. You need to have structured documents to take advantage of AXCM. Take the time to work through the tutorial with the supplied (structured) sample documents, this will give you a better idea of what this is all about.

- Michael

I see.

Need to learn how to walk first, eh?

Whilst I'm here, can anyone point me to some good articles/tutorials/videos on creating a structured document?

Frustratingly, I'm a demon at actually using structured Framemaker, but have never taken on the role of architect before.

[Russ Ward]

bowen192,

If you are a demon at using structured documents, you shouldn't be far at all from complete Satan of the EDD. This document is a set of instructions that tells what elements go where and what formatting should be applied; that is, it controls what you see in the element catalog at any given time. There is, unfortunately, not much in the way of simple, beginner tutorials out there. With a bit of patience and caffeine, though, some study of the Structure Developers Guide should get you going. This document installs with FM, or at least it used to. If you can't find it locally, search the web and you should be able to find it.

It is always helpful to have examples. FM installs with some structured template examples that might help. Warning - don't use the DITA EDDs and templates for this purpose. These definitions and the accessory software that drives them is very complex. Maintenance of a DITA architecture is not for the beginner.

If you downloaded AXCM, you can find some sample files in the ZIP that are used with the tutorial. They might be good to use as an example, as the EDDs are very simple. You can export the EDD from any of those files with File > StructureTools > Export Element Catalog As EDD (or, for later versions of FM, the StructureTools menu is in the main menu bar).

There are a number of folks that lurk around these parts who would be happy to help you with any specific questions you might have along the way. Note that you should post them in the Structured FM forum though, so you don't irritate the unstructured sycophants like Peter (I'M JUST KIDDING)

Russ

[Van Kurtz]

Bowen,

To add to Russ' comments....

If you have a structured template that you use a lot and are very comfortable with, you can export the EDD from it, as Russ said, and look through it (with the structured applications guide at your side) and see how it is done for your template. This avoids having to get used to an example template that is new to you.

Although there is a version of the structured applications guide for each version of FrameMaker, it does not always get released along with the FrameMaker application itself; however, the guide does not change much each time. The guide for Fm9 is available at the Adobe site. I have not seen v10 yet, if available.

Van

[bowen192]

Cheers Russ and Van.  I wasn't expecting such a comprehensive reply to be honest.

I've had a good read through the Structure Developers Guide 400 odd pages and, well, there's alot! I think this will be something I slowly develop whilst writing the manuals in unstructured.  Especially as there are format issues that must be present in the document.

Thanks again and if anyone's interested I'll probably update every week or month.

Probably.

[adrianaharper]

Thanks to everyone who contributed to this discussion. The debate rages on in my world as to if I'm moving or not... But at least I have more to go on, now! It also appears as though there is entirely more to consider than the management of conditional text.

Any additional comments, resources, thoughts, etc. are welcome.

Thanks again to the community here,

Adriana