Sparx Systems Forum
Enterprise Architect => Suggestions and Requests => Topic started by: MarkDavies on February 23, 2007, 10:00:52 am
-
Hi there
When documenting the basic flow and alternate flows (the bread and butter of use cases) it would be extremely useful to be able to use the features of rich text - that is, bold, italic, underline, colour, font, etc
This formatting could also persist on the rich text project reports "Project | Documentation | Rich Text Format (RTF) Report" from the menu bar.
There may be other text boxes in EA that could benefit from being able to record in rich text.
Personally, I would like to be able to make all glossary items bold in my scenarios, but cannot at the moment.
Any chance of including this feature in an software update soon?
Best regards
Mark Davies
-
This sort of thing has often been suggested, a common theme being rich text notes for various elements etc.
While there's not been such a feature added yet, we live in hope...
-
Or you start loving TeX
-
While there's not been such a feature added yet, we live in hope..
I hope to live that long.
bruce :-X
-
Just to second (or third, or fourth) this topic, this would be a tremendously-useful feature. The only resistance we ever get internally to using EA for all documentation is that people complain about the lack of rich formatting capabilities. We've written our own plug-in to generate Word documents from EA with a special template, and the only thing we're missing is formatting of the notes text. It doesn't have to include tables, but just the ability to use bulleted lists and font formatting would be huge.
-
I must admit that this would probably prove useful for us too.
-
I fully agree on this topic. I introduced EA at a number of companies and this is always a difficult point. When you look at an open source product like EPF then they have an RTF editor available for all topics. A feature like that would be a big improvement.
-
Ditto for us - the main thing preventing us using EA as our primary documentation is the lack or rich text and a proper editing facility in the notes field. Currently we copy and paste the main diagrams to word documents (yuk!) and add text around this - fast becomes a maintenance nightmare though!
-
Spidie,
IMHO...
Your problem could be (considerably) alleviated by an add-in or automation application. Such an app would peruse a model and produce the documentation you want, perhaps inserting it in a Word (or other) template designed to your specifications.
While this is a bit of work, it quickly provides net positive benefits if you need to produce a fair amount of documentation - that's total production, including repeated iterations throughout a project. It sounds like you're running up against this fairly often, so it is likely that you are good candidates for getting positive return in the (possibly very) short run.
If you take this route you can 'close the loop' for more benefits. You can import information into your models, normalize (to whatever standards you define) the information within your models, and provide automation support for standardized forms and formats, to name a few.
David
-
I too would "second" this request.
Like other respondents on this thread, I have seen this stated as a negative.
I suggest going further than the original suggestion and have synonyms in the Glossary (and maybe also an optional pre-defined thesaurus) so that incorrect use of terms can pop-up a selected Glossary list from which the user can select or to which the user can add if it is a genuinely new term.
As the previous poster said, uses of glossary items would be highlighted automatically where appropriate.
Also when writing descriptions maybe highlighting an item or pressing a control key would pop up a new entry dialog for the Glossary (not sure if this already mentioned).
-
RT for notes and scenarios would be an immensely useful feature. I run use case and robustness analysis sessions and I could save myself significant amounts of time and eye strain if I could adjust the font size and appearance of the editor window. It would also be useful when generating documentation to preserve formatting within the use case text.
-
Add a vote from the company I work for.
We are in the process of evaluating UML tools to replace Rational Rose, and a feature like this would have meant an easy win for EA.
Personally I probably would not use a feature like this. I've been perfectly happy with plain text (ALL the text in my documentation is important, otherwise it wouldn't be there ;D), and I'm a bit afraid of the end results once the analysts get hold of RT formatting to document their usecases.
You all know these kind of documents where the major part of the text is either in bold, italic, underlined, or even worse with [glb]shadows[/glb], different [size=12]si[/size][size=13]zes[/size] or color :-X
-
Just to clarify... from my POV... as a general requirement
Bold Mandatory
Italic Mandatory
Underline Mandatory
Strikeout Mandatory
Preformat
Mandatory
[size=32]Size[/size] Not required
Font Optional
Colo(u)r Optional
Super Mandatory
Sub Mandatory
"Code" Desireable
http://Hyperlink Moderately Desireable
[email protected] Optional
;D Smiley >:( Extremely undesireable
.. add your votes
There is (are?) a plethora of (ick) ActiveX (/ick) controls available to do this. There are even .. oh blah blah..
bruce
bruce
-
As a matter of fact, I think that it would be a good eough if we could add sorts of tags to defined the markup to be generated (as in html, latex, or old email systems).
For example:
_underscore_
*bold*
- bulleted list with hyphens
* bulleted list with bullets
TAB for indenting the paragraph
... maybe a few more.
I even think that more than this would be too much. As Geert said, all the text is important and the attention should not be driven away by fancy markups. In addition, the presence of many style buttons would clutter the element window.
Definitively: plain text with markups.
A.S.
-
...There are even .. oh blah blah..
bruce
bruce
Oh. Hickups? ;D
-
Hiccups!
No I had a good long talk to myself about it and all three of us agreed (but one of us refuses to commit himself).
;D
bruce
-
As a matter of fact, I think that it would be a good eough if we could add sorts of tags to defined the markup to be generated (as in html, latex, or old email systems).
For example:
_underscore_
*bold*
- bulleted list with hyphens
* bulleted list with bullets
TAB for indenting the paragraph
... maybe a few more.
I even think that more than this would be too much. As Geert said, all the text is important and the attention should not be driven away by fancy markups. In addition, the presence of many style buttons would clutter the element window.
Definitively: plain text with markups.
I think there's something to be said for keeping it simple. Perhaps additional tags could be added, with an option to ignore those that are not recognized (as with later RTF versions). We could then tag these fields for use in add-ins etc.
If something really fancy were needed, perhaps we could define these as reference data and transfer them that way. I don't know if the SDK (embedded or otherwise) yet supports custom reference data, but this would be a possible example.
David
-
As Geert said, all the text is important and the attention should not be driven away by fancy markups.
Yes, all text is important, but, to paraphrase George Orwell, "some is more important than others".
By this I mean that the ability to apply definitive styles to text, is a way of attaching metadata to the term. Thus even though the rendering of the text may be identical, the different style imparts information about the nature of the term.
A principal use of this would be to style a term <modelItem/>. This would allow a dictionary to be composed of all the "items" in the model and automation could be used to cross-check/refactor.
In any event SOMETHING, needs to be done real soon!
Paolo
-
One more vote for adding support for rich text content.
One of EA's biggest strenghts is the ability to publish models in popular presentation formats.
I cannot over-stress the importance of professional looking content. EA has the beef, just needs the sizzle..
-
I too think it should be kept simple as far as text styles are concerned. It only needs bold text linked into the glossary. More than that would be too much in my view.
The idea of visible tags has pros and cons but I think on the whole, for readability, I would like it bold and for the actual tag to be invisible. I still think an interactive link with the glossary (by double clicking) is necessary as per my previous comment.