[Framers] FM 2017 Feature Request: Restore color and scaling to menu icons

[Peter Gold]

​Hi, Stefan:

Thanks for your detailed reply.

Again, with all due respect, your short history with FrameMaker puts you at
a disadvantage, because, over the decades, many of the detailed recent
feature enhancements, additions, and bug-fixes you noted, have been kicked
to the "for future action" lists many times over.

We do appreciate the effort it's taken all the team members to achieve
these improvements. We've never doubted the sincere dedication that the
FrameMaker developers and teammates bring to the challenges of moving FM
forward.

However, the over-arching reality is that the decision-makers who apportion
the bare-subsistence budget to development are in control, so despite the
good intentions and dedication of the development team to meet the
competitive needs and customer/user requirements and requests, they
continue to exist in the same borderline-survival mode.

One of the earliest and perennially-reappearing feature-enhancement
requests that I can remember was the ability to resize the text size of
menu commands, with the corollary request to be able to resize dialog boxes
and their contents. Over the years some smart folks figured out
operating-system tweaks and hacks that offered some help here, but the
difficulty of bringing the feature into the product indicates the flawed
architecture.

I can't remember how many years of requests it took until FM finally got a
multiple-Undo history feature. The mantra excuse from early-on was
"re-engineering to support that feature takes resources and time we do not
have. Sorry. Maybe next release. Thanks for your request." I built a kludgy
substitute with a keystroke-recording utility in the early days, just to
have a tool for my needs.

In 1994, I joined an independent Sun Computer reseller as their FrameMaker
trainer. Their customer names included nearly all the major high-tech
companies in Silicon Valley. (Oh, where have they gone? We turn our lonely
eyes...) They had just introduced an add-on that gave FM tables the ability
to perform like spreadsheets. It became successful, so they tried to
interest Frame Technology in licensing it. However, just then, Adobe bought
FM, and they turned it down, because "we have plans to build that into a
future release." That never happened. Maybe it was the scarcity of
resources? Hm... Some years later, I learned from the CEO of my company,
that he'd thought of it one day, and gave it to a couple of programmers who
built it in a few days. It worked, solved a user need, sold well, had
value, and then became a part of history, because they were expecting Adobe
to make it and pre-empt their opportunity.

What's really surprising and ennobling about FM, is how much the original
designers and developers got right about it - from the earliest releases,
FM reliably did so much of what enterprise-scale technical authors needed.
What's disappointing has been how hard it's been to improve the process and
underlying engineering to efficiently evolve it.

​Thanks for inviting participation in the conversation. However, realize
that every time a user encounters a persistent sore spot in their workflow,
all the warm fuzzies and reassurances lose their value.​

​Again, just my opinions.
​


On Fri, Mar 17, 2017 at 1:09 PM, Stefan Gentz <gentz at adobe.com> wrote:

> Hi Peter,
>
>
>
> thanks for your honest feedback! Please allow me to answer a little bit
> more comprehensive (sorry, if it became a little bit long …)
>
>
>
> > There's always been the sense in replies to user requests, that users
> > who ask for product improvements and enhancements are whiners
> > who aren't satisfied with an already-great product.
>
>
>
> I cannot comment on the past as I joined Adobe just a little bit more than
> a year ago (and personally never made this experience), but I can say for
> sure that not a single one of my colleagues in the Adobe TechComm team as
> it is today has in any way an attitude like this. In the contrary. We are
> all very passionate about the product, actively listen to the users and
> take every feedback and suggestion very seriously. I know this sounds very
> much like marketing blah-blah, but that’s exactly how it is. Since I
> started at Adobe I had virtually hundreds of one on one conversations on
> conferences around the world actively collecting feedback, channeling it
> and bringing it into the system. A huge amount of this went into the 2017
> release.
>
>
>
> > The countless technical authors and communicators who have
>
> > used FrameMaker to create this priceless collection of information
>
> > deserve respect when they suggest and request improvements in
> > the product they rely upon daily and know intimately.
>
>
>
> Absolutely! I could not agree more on this. And you can be sure that
> everyone in the Adobe TechComm team has exactly this attitude and
> appreciation of the community. Again, I cannot comment on the past, but
> both the product management and myself listen very carefully to all the
> suggestions and requests for improvements.
>
>
>
> We do listen to the community and in both the 2015 and 2017 release we
> have implemented a lot of requests from the community. Some things are very
> small and might not even get noticed. But in both releases there are
> several thousand (!) smaller and bigger changes and improvements based on
> exactly such feedback.
>
>
>
> E.g. some users wanted FrameMaker to remember the “Find/Change” history.
> Done in 2017. Others told us, that the organization of entries in the
> find/change drop downs is chaotic and not logical to access. Fixed in the
> 2017 release. Others wanted to get the behavior in the “Files save as”
> dialog changed to stay in the same file format of the currently open file
> and change the file extension automatically when you change the fle
> format in the drop down. Done in the 2017 release. Others wanted get a
> faster and more easy way to insert graphics. Done in the 2017 release.
> Others wanted to get several dialogs resizable. Done in the 2017 release.
> Others wanted to get the spelling checkers better and behave differently
> (not so “over-aggressive”). We updated them to the latest engines available
> on the market in the 2017 release and changed the behavior to match the
> writing process better. Others wanted to get a better overview in the
> conditional tags pod by seeing the colors of the conditions. Done in the
> 2017 release. Others wanted to get text tabs back in the designer pods and
> get rid of the icons. Done in the 2017 release. Others asked us to finally
> get rid of the old, wired console window and make it a pod. Guess what?
> Done in the 2017 release. Others strongly requested to make dynamic content
> feature available for DITA based in attributes. Done in the 2017 release.
> Several DITA authors asked us to show the current element position in bread
> crump like path. Done in the 2017 release. Others complained about several
> issues when authoring DITA (like the behavior when you click return in a
> list item). Done in the 2017 release. Others wanted to make us the HTML5
> output Section 508 compliant. Done in the 2017 release. Or improve the way
> CSS are generated and managed. Done in the 2017 release. Others demanded
> support for high-dpi screens. Done in the 2017 release. Others wanted to
> have the setting for borders and text symbols a “global” setting and
> finally no longer a “by document” setting. Done in the 2017 release. And so
> on. In total there are over 1,300 smaller and bigger changes in FrameMaker
> 2017 and most of them are based on feedback from the users.
>
>
>
> > One of the fundamental issues that have crippled FM development,
>
> > going back to the 1990s is it's original engineering architecture.
> > Over the years, it's been patched in many truly genius ways, to be
> > able to provide more and newer features. However, the more
> > complicated the patchwork has become, the more difficult it has
> > become to evolve.
>
>
>
> In the 2015 and 2017 releases a huge amount of work went into the core of
> the product. In Fm 2017 the font engine was completely reengineered (to
> make FrameMaker compatible with RTL languages (like Arabic, Farsi and
> Hebrew) and complex script languages (ike Thai). Today you can author
> virtually all languages in the world with FrameMaker. In the 2017 release a
> huge part of FrameMaker was reengineered to make FrameMaker’s user
> interface technology fit for the future. Beside this a lot of ground work
> in the code was done to set the foundation for future developments.
>
> Most of this is not visible to the end-user, but it was necessary ground
> work in the background that had to be done. In many aspects FrameMaker 2017
> is a much more modern product today “under the hood” and in many aspects
> the foundation is set for the future. It might not be “visible”, but we had
> to do this and you can be sure, that we will continue to make FrameMaker
> the best tool for technical writers.
>
>
>
> > Perhaps it's time, within Adobe, to give FM the world-class
> > recognition its earned over the decades, give it the development
> > budget it deserves, and retire the obsolete engineering model,
> > as well as the obsolete lame excuse.
>
>
>
> Oh yes! Believe me, everyone in the Adobe TechComm team would love to get
> a bigger budget. And we’re fighting for it everyday competing with other
> business units J
>
>
>
> But to be realistic … just look at every normal company. I guess more or
> less all of you have made this experience: How big is the budget of the
> marketing department? And how small is the budget of the tech comm
> department? Right. And guess what? Adobe has excellent tools for creatives
> and marketing … and excellent tools for TechComm. I guess you get the idea
> J
>
>
>
>
>
> Regards,
>
> *Stefan Gentz*
>
> Adobe Worldwide TechComm Evangelist
>