Balance between fixing bugs and adding features
Balance between fixing bugs and adding features
I am bit disappointed in v5.0 of Flare that so much effort has gone into DITA support. I realize DITA is important but personally I can live without it for the moment. I was hoping to see more bug fixes especially for PDF output. What do other people think, has Madcap got the right balance between fixing bugs in existing features (particularly bugs that cause a lot of problems) and adding new features?
Poll: Flare 5.0 was the balance right between bug fixes and features
· 100% Right · 70% Right · 30% Right · 10% Right · (Results)
Poll: Flare 5.0 was the balance right between bug fixes and features
· 100% Right · 70% Right · 30% Right · 10% Right · (Results)
-
RamonS
- Senior Propellus Maximus
- Posts: 4293
- Joined: Thu Feb 02, 2006 9:29 am
- Location: The Electric City
Re: Balance between fixing bugs and adding features
While I am one of the harshest critics of MadCap I do need to defend them when it is applicable, as I think is in this case. First of all, MadCap is a comparably small company that competes with companies ten times the size or even larger. The competition is in the market way longer than MadCap, although the core MadCap team is in the industry for around 20 years.
Also, keep in mind that MadCap has to run a business. So while fixing dozens of bugs may seem to make sense for the outsider, it may be a really bad business decision to do so. Since resources are limited something has to give. Either new features are added or existing ones are fixed or enhanced. In both cases customers send in requests and I am sure that the sales and product management team has a close look as to what is going on in the industry. So we end-users may not have all the facts available that lead to the decision to favor this over that.
I genuinely believe that MadCap wants to do it all. Fix all bugs, add all features, and deliver a kick butt package right on time before all our project deadlines. Resources like developer time, QA time, and above all money are limited, which puts a wrench into the gears. MadCap lives on two source of revenue, one is sale of new licenses and the typically more lucrative sale of support contracts. Accountants love annuities. So a decision was needed to figure out what will increase revenue. Given that there is still a lot of market share to grab the focus is likely on growing the customer base. So by adding DITA a whole new ecosystem of hungry paying tech writers comes into focus and it may take until V6 that Flare is good enough in regards to DITA to be a serious platform.
Sure, I'd rather see full ODF support than DITA. I also think that a lot of other gimmicks like WebHelp AIR are useless at the moment (WH AIR doesn't do CSH), but I am just one of thousands of users and not even one of those who are potentially new customers.
At my work I recently was involved in long and painful discussions about a new feature. Sales asked for it and after going back to sales a few times they outlined what exactly the new gizmo is supposed to do. Development then looked at it closer and determined that a lot of different areas are affected and need to be changed quite extensively to make this work. Since we have data to work with for good estimates we were able to put a price tag on this new feature. That number went back to sales and the outcome is that sales can sell a few more licenses, but by far not enough to make the ROI that the company is looking at. So we decided not to add this feature and rather do something else, add a different feature and do more bug fixing.
The same debates are going on at MadCap and I am sure they make the decisions that make sense for them as company. Sometimes they make bad decisions, such as not having native PDF support right from Version 1. Sometimes decisions are made that I not only do not like, but do not understand at all (for example not allowing to customize and de-MadCap-isize DotNetHelp). But while I can complain publicly and directly to MadCap (which is more work, but also more effective) it is just another opinion. In that sense the results of your survey may provide some conclusion, but that conclusion may not be anything that makes business sense to MadCap. Flare and the whole application suite hasn't matured enough to focus on maintenance mode and fix bugs. That is a step that can only be done when The Next Generation of MadCap's tools is already in planning and worked on. The market pace is too fast to just lean back and fix bugs for a few versions. That is what Adobe/Macromedia did with RoboHelp (and not even that) and it gave grounds for a company like MadCap to come along and make a big impact. I think the folks at MadCap are smart enough to make sure that this doesn't happen to them.
What I recommend is that you write a list of which bugs you think are must fixes. Make sure to add a solid business case for each of them. The more convincing your arguments are the more likely it is that MadCap will be on it. I did that when Flare first came out and a good chunk of those issues got resolved in the first versions. But keep in mind, what may make you happy may not be of any concern for many others. In that case MadCap is better served in loosing you as a customer when that means retaining ten others. MadCap wouldn't do that because they are mean, but because they want a sustainable business that pays for their income that secures their outcome. And still, MadCap is about the most responsive software company I ever dealt with. Look at Microsoft as a contrast or example on how not to deal with your customers (but since we all still buy Microsoft they don't have to listen to customers).
Also, keep in mind that MadCap has to run a business. So while fixing dozens of bugs may seem to make sense for the outsider, it may be a really bad business decision to do so. Since resources are limited something has to give. Either new features are added or existing ones are fixed or enhanced. In both cases customers send in requests and I am sure that the sales and product management team has a close look as to what is going on in the industry. So we end-users may not have all the facts available that lead to the decision to favor this over that.
I genuinely believe that MadCap wants to do it all. Fix all bugs, add all features, and deliver a kick butt package right on time before all our project deadlines. Resources like developer time, QA time, and above all money are limited, which puts a wrench into the gears. MadCap lives on two source of revenue, one is sale of new licenses and the typically more lucrative sale of support contracts. Accountants love annuities. So a decision was needed to figure out what will increase revenue. Given that there is still a lot of market share to grab the focus is likely on growing the customer base. So by adding DITA a whole new ecosystem of hungry paying tech writers comes into focus and it may take until V6 that Flare is good enough in regards to DITA to be a serious platform.
Sure, I'd rather see full ODF support than DITA. I also think that a lot of other gimmicks like WebHelp AIR are useless at the moment (WH AIR doesn't do CSH), but I am just one of thousands of users and not even one of those who are potentially new customers.
At my work I recently was involved in long and painful discussions about a new feature. Sales asked for it and after going back to sales a few times they outlined what exactly the new gizmo is supposed to do. Development then looked at it closer and determined that a lot of different areas are affected and need to be changed quite extensively to make this work. Since we have data to work with for good estimates we were able to put a price tag on this new feature. That number went back to sales and the outcome is that sales can sell a few more licenses, but by far not enough to make the ROI that the company is looking at. So we decided not to add this feature and rather do something else, add a different feature and do more bug fixing.
The same debates are going on at MadCap and I am sure they make the decisions that make sense for them as company. Sometimes they make bad decisions, such as not having native PDF support right from Version 1. Sometimes decisions are made that I not only do not like, but do not understand at all (for example not allowing to customize and de-MadCap-isize DotNetHelp). But while I can complain publicly and directly to MadCap (which is more work, but also more effective) it is just another opinion. In that sense the results of your survey may provide some conclusion, but that conclusion may not be anything that makes business sense to MadCap. Flare and the whole application suite hasn't matured enough to focus on maintenance mode and fix bugs. That is a step that can only be done when The Next Generation of MadCap's tools is already in planning and worked on. The market pace is too fast to just lean back and fix bugs for a few versions. That is what Adobe/Macromedia did with RoboHelp (and not even that) and it gave grounds for a company like MadCap to come along and make a big impact. I think the folks at MadCap are smart enough to make sure that this doesn't happen to them.
What I recommend is that you write a list of which bugs you think are must fixes. Make sure to add a solid business case for each of them. The more convincing your arguments are the more likely it is that MadCap will be on it. I did that when Flare first came out and a good chunk of those issues got resolved in the first versions. But keep in mind, what may make you happy may not be of any concern for many others. In that case MadCap is better served in loosing you as a customer when that means retaining ten others. MadCap wouldn't do that because they are mean, but because they want a sustainable business that pays for their income that secures their outcome. And still, MadCap is about the most responsive software company I ever dealt with. Look at Microsoft as a contrast or example on how not to deal with your customers (but since we all still buy Microsoft they don't have to listen to customers).
New Book: Creating user-friendly Online Help
Paperback http://www.amazon.com/dp/1449952038/ or https://www.createspace.com/3416509
eBook http://www.amazon.com/dp/B005XB9E3U

Paperback http://www.amazon.com/dp/1449952038/ or https://www.createspace.com/3416509
eBook http://www.amazon.com/dp/B005XB9E3U
-
KevinDAmery
- Propellus Maximus
- Posts: 1985
- Joined: Tue Jan 23, 2007 8:18 am
- Location: Darn, I knew I was around here somewhere...
Re: Balance between fixing bugs and adding features
To add to RamonS's points (which are spot on IMO) DITA is still an emerging technology, but one that is picking up steam and becoming a standard when it comes to portable structured documentation. Part of it being an emerging standard is that no single tool has nailed down the market as the standard tool to work with DITA projects in--this market is still available for new entrants. That may not be the case in 2-3 years, though, so any company that wants to become a major player in DITA authoring would be well advised to stake out some territory now. If Madcap were to focus solely on fixing existing issues and leave new markets for later, there is an extremely good chance that those markets will be dominated by a major player at that time (such as Adobe). And if DITA really takes over the documentation market and Madcap lets it slide, Madcap risks being made permanently a niche player, possibly even unviable. (And if they go out of business, there won't be any updates at all for Flare....)
Until next time....

Kevin Amery
Certified MAD for Flare
Kevin Amery
Certified MAD for Flare
Re: Balance between fixing bugs and adding features
I'll admit that I know little about DITA and there isn't much call for its use at this company. On the other hand, I'm the only author, so we're not big enough to need DITA, not that size is the only factor. My first exposure to the term DITA was two years ago at the WinWriters conference, and there were a LOT of presentations geared around DITA at that time, so even though you may not use DITA, there are apparently a lot of companies that do, or will in the near feature.
Lisa
Eagles may soar, but weasels aren't sucked into jet engines.
Warning! Loose nut behind the keyboard.
Re: Balance between fixing bugs and adding features
awww....RamonS going soft on us...
Very insightful business and industry commentary. All very well put. from everyone else.
About DITA, crossing into new territory isn't new for the MAD team - i could be wrong- but i think when r---help came out this same team was responsible for being the first in the industry to support HTML for a HATT.
But I think this time around they had to spread out their top engineers effort out not in Flare/Blaze but in another product as yet unseen - Team Server. Without any inside information at all, my guess, is that mr mike, sharon, bjorn and oliver have been hard at work putting their combined marketing/business brains, long industry experience, and software architecture/XML chops to carve this fella out. They've done HATTs for years, but I think this might be new territory for them. Its gonna be a challenge. The closest was the r-b- source control application i think.
There is no news on this yet but 'I've just got a feeling on this'.
Looking at the forums, it looks like the number of people putting out 1,000 - 5,000 topic Flare/Blaze projects out there now is not uncommon. I can only imagine the build times on these projects must be ridiculously long. I can't even make it to 100 without losing my head sometimes...
As an aside, have you had a go with Capture 5? They've put in some new features in there as well to make it a little more of a compelling screen capture alternative to the established entrants in this area. There are some [minor] features for print in there as well.
Am sure the poll results will be interesting.
Its nice to see posts like these on the forums on occassion. Kind of enjoy it.
Very insightful business and industry commentary. All very well put. from everyone else.
not forgetting iand, you are not wrong. But i doubt they're going to make a massive release like Flare 4 for awhile. In fact, most of the features were print related and actually came more from the Blaze frame-maker alternative offshoot. It was like two product releases in one.iand wrote:I am bit disappointed in v5.0 of Flare that so much effort has gone into DITA support. I realize DITA is important but personally I can live without it for the moment. I was hoping to see more bug fixes especially for PDF output. What do other people think, has Madcap got the right balance between fixing bugs in existing features (particularly bugs that cause a lot of problems) and adding new features?
Poll: Flare 5.0 was the balance right between bug fixes and features
· 100% Right · 70% Right · 30% Right · 10% Right · (Results)
About DITA, crossing into new territory isn't new for the MAD team - i could be wrong- but i think when r---help came out this same team was responsible for being the first in the industry to support HTML for a HATT.
But I think this time around they had to spread out their top engineers effort out not in Flare/Blaze but in another product as yet unseen - Team Server. Without any inside information at all, my guess, is that mr mike, sharon, bjorn and oliver have been hard at work putting their combined marketing/business brains, long industry experience, and software architecture/XML chops to carve this fella out. They've done HATTs for years, but I think this might be new territory for them. Its gonna be a challenge. The closest was the r-b- source control application i think.
There is no news on this yet but 'I've just got a feeling on this'.
Looking at the forums, it looks like the number of people putting out 1,000 - 5,000 topic Flare/Blaze projects out there now is not uncommon. I can only imagine the build times on these projects must be ridiculously long. I can't even make it to 100 without losing my head sometimes...
As an aside, have you had a go with Capture 5? They've put in some new features in there as well to make it a little more of a compelling screen capture alternative to the established entrants in this area. There are some [minor] features for print in there as well.
Am sure the poll results will be interesting.
Its nice to see posts like these on the forums on occassion. Kind of enjoy it.
If you submit your bug feedback request here, the more likely it'll get fixed or included in a future release
Open Utilities PageLayout Resizer for Flare/Blaze | Batch builder
Open Utilities PageLayout Resizer for Flare/Blaze | Batch builder
-
RamonS
- Senior Propellus Maximus
- Posts: 4293
- Joined: Thu Feb 02, 2006 9:29 am
- Location: The Electric City
Re: Balance between fixing bugs and adding features
Well, sometimes reality settles in, hehe. It is that I know work as QA lead with small development teams. One project has five developers and the project I currently work on has two developers that work also on different projects. Since we were bought like a larger company some time ago budgeting is different. Before we could just do things because we thought they would be kewl, now anything with a solid business case is kewl. It is impossible to make everyone happy so hard choices need to be made. Sometimes that is really frustrating, especially for QA. Knowing that there are bugs in the software and it gets shipped that way just bugs me a lot, but I am not the customer and as long as the customers don't complain it is not highest priority.forfear wrote:awww....RamonS going soft on us...![]()
The danger here is that adding features and not fixing bugs over time degrades the overall quality of software. Bugs don't go away and eventually they must be fixed. Bug fixing is the most boring and thankless developer task. It is tedious and does not advance the feature set of a product. What works well at my place is that we schedule time for bug fixing, typically a block of three weeks for each developer. Product management and the BAs together with the QA manager and often support go through the bugs that were logged and come up with a list that has bugs to fix that generate the biggest improvement. Even with features to add we usually focus one semi-annual release on support and one on sales, because in our industry there are times during the year when it is better to introduce new features.
One mistake that many software shops make is that they put the junior developers or the less skilled ones on the bug fixing job. While that may familiarize them with how the whole thing works it typically generates more other bugs, especially when you got the type of developer that only fixes exactly what was reported, but leaves the crooked text boxes and spelling errors in place. And sometimes it is better to leave something broken than to fix it, because a fix would have to be so restrictive that it becomes more an annoyance. At my work we just undid a fix, because in some cases the restrictions of this fix can lead a customer into a hole where they cannot get out of. The real solution would be a complete redesign, but that affects half of the features and is not reasonable to eliminate what really is more an annoyance. I used to cringe and get worked up about this, but one has to keep all customers in mind. Fixing a bug to make a few dozen happy isn't worth it when hundreds other have to suffer from it. But we did our due diligence and can get back to the few dozen customers and explain them exactly why we did not fix this or that. Most of the customers understand when you give them a plausible reason. And that is probably the area where MadCap can improve more. Why the heck don't you make it so that one can take the MadCap stuff out of the DotNetViewer? Why is WH AIR not CSH-capable? Why do you blatantly ignore ODF? And why do you add instant messaging and XPS support? If I want IM I use a real client and nobody uses XPS.
New Book: Creating user-friendly Online Help
Paperback http://www.amazon.com/dp/1449952038/ or https://www.createspace.com/3416509
eBook http://www.amazon.com/dp/B005XB9E3U

Paperback http://www.amazon.com/dp/1449952038/ or https://www.createspace.com/3416509
eBook http://www.amazon.com/dp/B005XB9E3U
-
Robotman
- Sr. Propeller Head
- Posts: 186
- Joined: Sat Mar 04, 2006 3:05 am
- Location: Melbourne, Australia
- Contact:
Re: Balance between fixing bugs and adding features
Firstly, I agree with Ramons completely. Secondly, it doesn't stop me being utterly frustrated at simple things not being fixed or improved.
I was quite happy to see the right-click enhancements with Hyperlinks / Cross References but the fact remains Flare doesn't remember your last entry and I struggle to understand why? These same frustrations I can level at other simple areas of the system too. DITA did nothing for me - it might in the future so I've got not problem it being there as others will get use out of it.
Our software goes through the same process. Bug fixes take a back seat to new features and whilst it might be the norm, it doesn't stop it being not good enough. Still, our software, like Flare, is useable and is fantastic. I just wish it was more streamlined.
I was quite happy to see the right-click enhancements with Hyperlinks / Cross References but the fact remains Flare doesn't remember your last entry and I struggle to understand why? These same frustrations I can level at other simple areas of the system too. DITA did nothing for me - it might in the future so I've got not problem it being there as others will get use out of it.
Our software goes through the same process. Bug fixes take a back seat to new features and whilst it might be the norm, it doesn't stop it being not good enough. Still, our software, like Flare, is useable and is fantastic. I just wish it was more streamlined.
Re: Balance between fixing bugs and adding features
Dear god above, PLEASE let Team Server be NOTHING like RoboSource Control.forfear wrote:But I think this time around they had to spread out their top engineers effort out not in Flare/Blaze but in another product as yet unseen - Team Server. Without any inside information at all, my guess, is that mr mike, sharon, bjorn and oliver have been hard at work putting their combined marketing/business brains, long industry experience, and software architecture/XML chops to carve this fella out. They've done HATTs for years, but I think this might be new territory for them. Its gonna be a challenge. The closest was the r-b- source control application i think.
There is no news on this yet but 'I've just got a feeling on this'.
Regarding bug fixes: There certains does have to be a balance, and I see very few software companies (including, frustratingly, the one I work for) who spend serious time and effort on any "bugs" that do not directly mess up data. I understand why not -- because if you were to polish up the product, most customers start asking where all the features are, and rightly so.
As a Flare user, personally, I'd forego the next entire release worth of features in exchange for a very serious effort on MadCap's part to streamline Flare, and resolve many of the inconsistencies and inefficiencies in its use (conditions are listed in alphabetical order when assigning them from the file properties dialog, but when assigning them by format within a topic, they appear in oldest to most-recent? how does that make any sense? or "how many clicks does it take to get to the tootsie roll center of the link you want to create?").
Flare v6.1 | Capture 4.0.0
Re: Balance between fixing bugs and adding features
Looking at the bug fix list for Flare 5
i think the madcap team really have put in a lot of effort into the release in terms of bug fixes..
http://kb.madcapsoftware.com/default_Le ... adCap-Skin
i've recognized a few of them, not all, but I think its quite a commendable effort. don't you think?
i think the madcap team really have put in a lot of effort into the release in terms of bug fixes..
http://kb.madcapsoftware.com/default_Le ... adCap-Skin
i've recognized a few of them, not all, but I think its quite a commendable effort. don't you think?
If you submit your bug feedback request here, the more likely it'll get fixed or included in a future release
Open Utilities PageLayout Resizer for Flare/Blaze | Batch builder
Open Utilities PageLayout Resizer for Flare/Blaze | Batch builder
Re: Balance between fixing bugs and adding features
Hi, good points everyone. I understand this is a tricky balance to strike. I think I may have had my devil's advocate hat on when I wrote this post! I have to say I am happy with the improvements that have been made in Flare 5 like the new xml source editor and the fact that print preview works much better. Anyway, I have to second the following:
>>As a Flare user, personally, I'd forego the next entire release worth of features in exchange for a >>very serious effort on MadCap's part to streamline Flare, and resolve many of the inconsistencies >>and inefficiencies in its use
My personal bugbears are:
1. Flare's CSS editor. I've given up on it totally and just use notepad to edit my Stylesheets. It doesn't seem to provide any productivity gain over notedpad. I think we really need wizards to help setup and modify list styles for example in the same way that we have a separate Table Style Editor, these have caused me no end of pain.
2. The lack of a firebug like feature to debug problems with CSS for printed output. I guess this would save Madcap Tech Support a fair bit of time.
3. The lack of backreferences for regular expressions in Flare's search and replace feature.
I think Flare is great for HTML help but trying to produce good printed output as well as good HTML help from a single source is really tricky and could be made easier.
>>As a Flare user, personally, I'd forego the next entire release worth of features in exchange for a >>very serious effort on MadCap's part to streamline Flare, and resolve many of the inconsistencies >>and inefficiencies in its use
My personal bugbears are:
1. Flare's CSS editor. I've given up on it totally and just use notepad to edit my Stylesheets. It doesn't seem to provide any productivity gain over notedpad. I think we really need wizards to help setup and modify list styles for example in the same way that we have a separate Table Style Editor, these have caused me no end of pain.
2. The lack of a firebug like feature to debug problems with CSS for printed output. I guess this would save Madcap Tech Support a fair bit of time.
3. The lack of backreferences for regular expressions in Flare's search and replace feature.
I think Flare is great for HTML help but trying to produce good printed output as well as good HTML help from a single source is really tricky and could be made easier.
Re: Balance between fixing bugs and adding features
Hi Forfear, I tried Capture and it seems fairly powerful but unfortunately the only caption arrows available are some giant curved orange things! I will have to stick to Snagit for now as I don't think I can make a case for Capture yet. I think the balance could shift in Capture's favour in the next release.
-
KevinDAmery
- Propellus Maximus
- Posts: 1985
- Joined: Tue Jan 23, 2007 8:18 am
- Location: Darn, I knew I was around here somewhere...
Re: Balance between fixing bugs and adding features
That's the default, but you can change it. Right click on the arrow and choose Properties. From there you can change the curve factor (setting it to 0 gives you a straight arrow) the colour, etc. I was able to make a straight arrow with a nice restrained grey colour in a few mouse clicks.iand wrote:Hi Forfear, I tried Capture and it seems fairly powerful but unfortunately the only caption arrows available are some giant curved orange things! I will have to stick to Snagit for now as I don't think I can make a case for Capture yet. I think the balance could shift in Capture's favour in the next release.
EDIT: and, once you have the arrow design that you like, you can right click on it again and choose "Set Default" and all the rest of your arrows from then on will look that way too.
Until next time....

Kevin Amery
Certified MAD for Flare
Kevin Amery
Certified MAD for Flare
Re: Balance between fixing bugs and adding features
Ah, that's where it was hiding! Perhaps they should make that a bit more visible
... I like my arrows a bit more restrained!
Re: Balance between fixing bugs and adding features
Yes, it should be a bit more English-like in a restrained kind of way, isnt' it?iand wrote:Ah, that's where it was hiding! Perhaps they should make that a bit more visible... I like my arrows a bit more restrained!
Haha!!! Seriously, I do agree with you wholeheartedly on more minimalist captions (its all user customizable). Captions shouldn't overimpose themselves and make themselves a star in a screenshot. The caption i use is usually the simple bubble or a custom numbered outlined circle which i create myself - as used in Vista help.
Try the new capture a bit. Give the batch processing features a run. I know other tools can do that too, including the one you're using.
if anything you could just use Capture to add callouts, IMHO.
There's depth to it. A lot of the features in earlier versions of Capture were not as easy to access. Give it some time. The new version shows important commands and attempts to work the way most ppl expect their screen capture tools to work. If anything just use the callout features.
If you submit your bug feedback request here, the more likely it'll get fixed or included in a future release
Open Utilities PageLayout Resizer for Flare/Blaze | Batch builder
Open Utilities PageLayout Resizer for Flare/Blaze | Batch builder
Re: Balance between fixing bugs and adding features
This is a very late reply, but thanks for pointing out that the arrows can be toned down Kevin! Musn't scare the users!! The default arrow is definitely not English, I think something more flamboyant, maybe it's Italian... 
Last edited by iand on Fri Jul 24, 2009 4:17 am, edited 1 time in total.
Re: Balance between fixing bugs and adding features
Glad i could shine a bit of light on anyone's day. 
If you submit your bug feedback request here, the more likely it'll get fixed or included in a future release
Open Utilities PageLayout Resizer for Flare/Blaze | Batch builder
Open Utilities PageLayout Resizer for Flare/Blaze | Batch builder