I've got manager types who would dearly love to be able to use simple formatting like underlines, bold, bullet points and so on, but our developers regularly paste code or error messages in which would be mis-rendered in this type of view.

So, while I'd love to be able to get the formatting type stuff in, this way of doing it can't work for us, and I'd have to stick to plain text!

The fact that users will not get why they type is making me rethink my deployment plan.

I thought the original plan for wikki markup was to use a wysiwyg type editor component? That would have avoided this problem.

Thank you for your feed back.

After reading your comments, I see that the main issue is that your users will find wiki formatting too cryptic to use. And thus the wiki formatting is completely useless in your environment. I can definitely understand where you are coming from.

Unfortunately we cannot make wiki formatting less cryptic. However, we believe some users will find wiki formatting useful.

When implementing JRA-1585 we decided to do it in stages, and WYSIWIG was left out of the first stage. We are hoping to deliver a WYSIWIG editor in the future. As such, would you agree if I turned this issue into an improvement to add WYSIWIG editor support?

Thanks,
Anton

Some of our lot would be perfectly happy with WIKI markup, but the
problem is that it depends on embedding special characters into plain
text, and a lot of those characters are likely to be pasted in as part
of an issue.

So, yes, this is a good idea, thanks!

One must be able to flag a text field as plain text or WIKI markup. If the user has to hit another button (tab?) to use/turn on the WIKI markup feature, then nothing will be broken for users who are simply entering plain text, or code snippets etc. But if they distinctly want to use the markup, they should have to hit a button tagging the text box as being WIKI markup enabled. Then, every process - whether it be an email notification or issue display - will simply display "as is" if it has been flagged as plain text (like the Excel output), or by interpreting the WIKI markup commands as the author intended. Otherwise there is no way the system can tell whether an "n" in parentheses was intended to be a thumbs down sign or not. Only the author can tell.
As an aside, for anyone who routinely uses Excel output to generate reports (as we do, for clients), the current implementation of the Excel output actually shows the markup tags, which would make these reports useless as well. I cannot present a spreadsheet to a client with a bunch of dashes and curly brace commands showing up. The Excel output has to be smart enough to convert the WIKI marked-up version into a plain text version, which it currently does not.
So, in summary, I cannot see how anyone could make use of this feature unless it was able to be toggled on and off on a per text box basis.

Would it solve the problem if using Wiki syntax was user configurable? So, an admin can turn it on or off for all the users, but each user can choose what they wish to use for themselves in their profile. So those users that want to use wiki syntax can and those the want to use the older non wiki syntax can as well?

I have no idea if this can be done or not or even if it solves Neal's problem, but to me it sounds like it might address Neal's concern.

For my part, I would love to use Wiki syntax and I think most of my users will as well, however, the upper management, which aren't the brightest people in the world might not want to use it, so I do see Neal's point.

Our users who want to use formatting would prefer to see formatting buttons that they can use after highlighting text, rather than having to enter raw wiki markup (many of them are used to the "media wiki" which offers this. It's only inserting the wiki markup for them, but it's good enough for us). The ability to turn the "wiki-interpretation" on and off with a flag is critical though.

Chanan's point about the user settings is also useful - ideally, each user would have a flag on their profile giving it a default of wiki or non-wiki, which they can then override on the occaisions they need to.

And yes, I agree, idealy the default I was talking about in the previous comment is just that - a default - however a user should be able to override it for each field that allows wiki markup.

No - seriously, we've considered a lot of different options when doing this. I do think the current option is the simplest.

The fundamental problem is that fields in JIRA are public. They're not private. This in itself needs to be factored into any thinking. For example, if one user creates an issue with a description in one 'text style', then another edits it unless you go through an expensive conversion process (which is likely to be very painful an error prone) - they must all edit in the same style.

Now do you have the user who creates the field / issue choose the style? That seems too arbitrary.

It also leads to confusion, as to 'what style' the current issue is.

The simple thinking is that administrators can decide on a per project basis, which fields they want to be styled. This way, users will quickly learn what they can and can't do where, and it's consistent.

The notation is not hard to learn, the help is very prominent (even more so in the public version), there's a preview option to help users, and for most entries, text will just appear as you type it.

User configurable and all these fancy options just over complicate things IMHO. As Anton said, we're going to add a new "WYSIWYG" text formatting option in a future release as well, that will give you a styled WYSIWYG editor - but again, there will be no conversion between different formatting styles - it's up to you to choose on a per field basis.

Hope that explains things a little more.

Cheers,
Mike

I have installed JIRA at 2 different companies and I can count on one hand the number of people who took the initiative to figure out how to customize their dashboard. I dare say, none of them are going to be interested in learning a new set of cryptic commands in order to achieve bold or italics, etc. anyway.

As to Excel reports, we export issue lists to Excel for a variety of purposes, as do other sites. We use them for status meetings with internal and external audiences. I am currently preparing an Excel report so I can report back to our client our progress on their issues. If the description field had all sorts of this and that, it would be unreadable. I mail and/or print these Excel reports to our clients so they can see issues they have reported. They do not access JIRA directly.

I appreciate you are trying to provide a feature the user group was asking for (although I wasn't one of them). Obviously, I won't be enabling this feature for any field, but I would be surprised if those who did would not encounter these problems as well.

I still say you need to be able to mark each text as "plain text" or "WIKI text". That's the only way to do this. Like in Word, when I type "" and it redisplays as a smiley face, I can either turn off the autoformat option or jusy undo the last autoformat.

I'll leave this issue, and you can create a new resolution "agree to disagree"

Neal,

Let me also disagree gracefully, but explain a little more carefully why. I think your points are quite clear (and realise that any feature development issue is never going to make everyone happy!).

1. If you don't like it - simply turn it off.
2. The "cryptic" commands are not cryptic at all. It's as simple as any markup could be and it's intended to be like email. From Confluence we know that people pick it up easily and often are surprised that the _emphasis_ they meant to put on a word just works.
3. The number of times markup 'clashes' is really very few. We can see this just by surfing issues in j.a.com which have markup turned on, > 95% of them (written without any knowledge of markup at all!) work fine.
4. for Excel, if you don't want this and that, don't put them in. If they're there, they're there for a reason - because you want to emphasise the word?

As for your surprise, we're quite enjoying it internally - but yes, we'll wait and see how the rest of the user community likes it before doing anything drastic. If they don't like it, I guess they'll turn it off and we'll go back to the drawing board!

Cheers,
Mike

But, I thought I'd try it in this call and am happy to say that it does what I need it to do which is allow entry of data without changing the formatting at all.

In my case everyone entering this type of data is fairly technical so learning the tags is not likely to be a problem. The main area that could be a concern is how the 25000 issues we already have in the system will display if it is enables.

Matthew

Example call data:

Parse failed: at 2005-10-10 10:35:38.240 ------------------------------------
Token: <aar_lfai> Script: "Sxxxx_Sxxxx.hgtransform" Ver: "28.3a"
                                                               \r
XXXXXXX XXXXXX XXXX IN PROGRESS PLEASE WAIT\r
{NO DIAGNOSTIC TO DISPLAY- 5   \r

threadStart(3048b0e6-201e);
in(hgcapi, 3048b0e6-201e, 2005-10-10 10:34:36.390,
    status = nvs_create_session("r5982pin15:1034333001721847213:NAX3L3QC2UGBWC\
10OJFGOEQ:Servlet.Engine.Transports:108", "itclive", "Sxxxx_Sxxxx", &sess_ptr)\
;
);
out(hgcapi, 3048b0e6-201e, 2005-10-10 10:34:36.390,
    nan_assert(status == 1);
);
in(hgcapi, 3048b0e6-201e, 2005-10-10 10:34:36.397,
    sr_ptr = srlite_load(hgcapi_tab(), "CLS_SEGMENT(CLS_AIR_SEGMENT(AA,!1450,Y\
,(9,11),SJC,EWR,NN,,,1,,,,,,,,(9,11)))");
    nan_assert(convert_nvs_cls_segment_t_sr_to_c(sr_ptr, (void*)&cmd_ptr));
    sr_srfree(&sr_ptr);
    status = nvs_sell_long(sess_ptr, 1, 0, cmd_ptr, (void*)&rsp_ptr, &err_ptr)\
;
}}

Yeah - i definitely won't be turning it on, so no worries for me. As to the Excel, if I wasn't clear.. the problem is that in order to get the advantage of the markup, users need to know that their markup tags will not make it into the Excel output. If a user has chosen to use the markup tags to make the issue display pretty, the report produced in Excel needs to know to ignore them. I would call that a bug. Otherwise, the Excel outputs will not be usable for fields that could have tags in them. Just like you have code to strip out HTML, you need code to strip out markup. Maybe in Confluence you don't have a use case for people exporting to and printing from Excel. But with JIRA I know I'm not the only one who uses it for status reports etc.

And Matthew's point is also another example of the problem. How does he know how it will render his 2,500 issues once he allows markup on that field. That's a lot of code that could get wonky on display. Over at j.a.com you probably don't put a lot of code snippets into comments, but others do.

BTW Mike - how did you get "emphasis" to show up like that without interpreting the underscores as italic markers in your comment?

  {noformat:nopanel=true}_emphasis_{noformat:nopanel=true}

Just a try:

Perhaps this could be an easy solution: Atlassian could provide a Radiobox or similar("show as plain" text or something like that) which automatically surrounds the typed text with this macro

http://jira.atlassian.com/browse/JRA-6906#action_38717

select count (*)

and it re-displayed as
select count

select count (*)

but if I turn it on I see select count
Just like the Excel output, it will display "as is" without trying to interpret the markup code.

I like this suggestion. Unfortunately, we will not have a chance to get this into 3.4. After that, we will see how the wiki mark up fares in the user community and return to this.