I'm going to be at PePcon 2012 in San Francisco next week (14-16 May). InDesign product management and several engineering leads will be there, and one of the things that they are specifically looking for is feedback and RIFs (Really Important Feature requests) (no, sadly, that's not a real acronym). Last year's conference directly resulted in a major addition to InDesign (PDF form creation directly in ID) that hadn't been in the plans, and I expect this year's will have a similar amount of leverage. Chris Kitchener, the InDesign product manager, has already intimated as such.

I want to bring a list of RIFs with me, promote gd.se to the Adobe people (and everyone else!), learn stuff and meet cool people. (John McWade, the "designer's designer" will be there, among others I've never had the pleasure of meeting in person.)


  • Bring me your tired, your poor, your huddled wishlists yearning to breathe free. I'll take any and all FRs posted here and pitch them to Chris, Kiyo and the rest of the gang. (Try not to ask for things that just got added to CS6!)

  • If you're going to be there too, let me know and we'll meet up. In fact, if you're based in San Francisco (lookin' at you, @Farray!) let me know; mayhap we can get together. Email me at [email protected] (temp address set up for this purpose).

  • Would love to make it but I'll be out of town. Hopefully others will be around!
    – Farray
    May 7, 2012 at 6:04
  • Next time I'm up there, then. I owe you a [beverage of choice] for all your help here. May 8, 2012 at 16:38
  • @AlanGilbertson How'd it go? Are you home yet? May 18, 2012 at 19:01
  • I wish we had a blog here... The conference was wonderful. InDesign users are some of the nicest people, so hanging out with 400+ of them is amazing. I lucked upon Chris Kitchener (ID PM) and Douglas Waterfall (Sr. Computer Scientist for InDesign) and got to spend about 3 hours one-on-one with them. They were really interested, really listening, and as passionate about InDesign as I am. Factoid: as of the release of CS6, they have over 1,000 feature requests outstanding. May 19, 2012 at 19:38

2 Answers 2


Wow, awesome!

Here's my request: make things like sparklines and better charts in reports possible by porting the Illustrator graph tool over, and setting it up so it can read from InDesign tables or (maybe this is pushing it) from sheets included in a PDF portfolio.

It's massively common for InDesign to be used for things like reports that include charts and graphs, and it makes sense to be able to set these up within InDesign rather than constantly having to fetch them over from other software. At the moment, at best, people place charts from illustrator, which is clunky, cumbersome and difficult to maintain; at worst, they drop them in as ugly, constrained raster graphics from programs like Excel - really bad for maintainability and bad for good design.

I'd love it to become commonplace for people publishing tables, appendixes etc to just casually drop in high power visuals like sparklines like it's not a big timeconsuming pain to implement. Right now, it's such a cumbersome, longwinded process that few ever do.

Here's an example of a table with sparklines for anyone who has no idea what I'm talking about (taken from http://www.joiningdots.net/blog/2006/10/dashboard-design.html). It turns a table into something interesting and engaging, without losing any of its power as a lookup reference tool. Like most such things currently, it's from a dashboard tool since design software doesn't yet handle this sort of thing well at all.

Sparklines example

If InDesign had its own graph tools, and if charts could simply be set up in brand style then pointed at the appropriate rows and columns of an existing table (which might be on the same page, in an appendix or hidden somewhere), who knows, great practices like sparklines might become commonplace and the world's reports would become more interesting and useful to read. (And picking up and updating someone else's .indd with fresh data would be simple rather than a massive pain...)

With data graphics becoming more and more of a popular topic (especially in the business world), this would give Adobe a hell of a strong USP and something that would be really compelling in demos to big corporate buyers.

If adobe aren't convinced that there's gold in them there hills, point out to them that these guys have been making a living since before CS1 charging $495 (no typo) for a rather limited and clunky looking InDesign and Quark plugin that offers rudimentary bar charts, pie charts and seemingly little else. And here's an Adobe Forum discussion showing I'm not the only person interested...

(and maybe if there are two applications making use of the Illustrator graph tool, it might just get an update that stops it looking and performing like it just stepped out blinking from a time capsule buried in 1995...)

  • I feel your pain... So this one is added to the list! May 9, 2012 at 3:52
  • By the way, have you checked out Chartwell (amazing OpenType font for generating charts). fontfont.com/how-to-use-ff-chartwell?aid=59 May 10, 2012 at 6:28
  • Wow, Chartwell is awesome! Not a perfect solution for all cases but an amazing one for some cases. To quote a certain Alan Gilbertson commenting on InDesign Secrets in 2011, "Woot!" indesignsecrets.com/creating-instant-charts-with-chartwell.php May 10, 2012 at 9:50
  • 2
    Ah yes, my deeply philosophic response to Chartwell... In other news, I talked this over with Chris Kitchener, who's now in charge of AI and ID, and Douglas Waterfall, the engineering genius behind so many of InDesign's power features. Charting has been a topic within the Illustrator and InDesign teams for some time. It's a non-trivial (to say the least) engineering challenge, but it is definitely on the radar. Keep pitching the request on the Adobe website, with the reasons why. It will help them prioritize things. May 19, 2012 at 21:17
  • That's brilliant, thanks so much! I feel that never before in the history of Stack Exchange has a comment deserved an upvote more... May 19, 2012 at 21:54
  • @AlanGilbertson Drat - I just had an idea that would have been much better suggested a week ago. So: charting involves non-trivial logic, and Adobe CS can be controlled by Javascript. The open-source JS library D3 contains loads of fantastic, non-trivial charting logic, in Javascript. Might it be a simpler, more future proof task for the engineers to create a wrapper around an existing library like D3 - a simple output layer that translates the co-ordinates D3 writes from browser/DOM/svg into application logic? I imagine they could use a lot of their existing SVG import code... May 19, 2012 at 21:59
  • ...and of course it would need to read the data. For this, I'd use tables in InDesign and placed CSV files in Illustrator (no point re-inventing the spreadsheet). So there could be three potentially straightforward engineering tasks: porting data into D3, a basic UI to select D3 options and settings, and converting D3's output into a format the application understands (possibly via the existing SVG conversion code). Oh, and a fourth: storing and re-applying appearance settings each time it's re-drawn. Just a thought. May 19, 2012 at 22:17
  • That's definitely worth suggesting as a feature request for BOTH programs. Chris Kitchener is now over both of them, and he does, indeed, read every feature request. Be sure to lay out why it is important for your workflow. May 20, 2012 at 20:06

The only feature request I really have is fitting a row or column to the size of the content in an InDesign table the way you can in Excel.

Having a placeholder for the absolute number of pages in a document would be nice too.

and THANK YOU ALAN for carrying our requests! :)

  • Noted! (And you're welcome!) I'm going to refer to this page while I'm there, besides taking notes. May 8, 2012 at 16:36
  • 2
    I pitched these points. Two valuable takeaways from my long chat with Chris and Doug were that a) Chris reads every feature request, and b) if they understand why a given feature is important (its "use case") they can pitch it internally to get the budget approval (finance, engineering resources and time) for it in a new release cycle. We can help them enormously by being as specific as possible when requesting a feature. May 19, 2012 at 21:22
  • That's a really really useful insight into how their internal process works. I've often written feature requests unthinkingly assuming that, if anyone reads them, it'll be a fellow experienced user. In future I'll make sure to write with an audience of engineers and budget overseers in mind, and I won't assume much experience as end users or designers. May 19, 2012 at 22:10
  • They listened with dropped jaws as I explained in detail why automatically migrating document presets, keyboard shortcuts and custom workspaces would allow a busy designer to migrate to "CS-Next" in a day rather than piecemeal over weeks. Up to that point, they'd considered it a minor "nice idea." So, yeah, it's important to let them understand the view from our trenches, and it was good for me to look at it from their trenches. :) May 20, 2012 at 20:13
  • 1
    @AlanGilbertson: Dropped jaws indeed! WHY don't they ever have actual trench workers on these design teams? May 20, 2012 at 21:43
  • On the team would be hard. There are too many different workflows. Freelancers like me need efficiency, use many suite apps, and tend to see things others might not. OTOH, there are agency and magazine folks, newspaper people, textbook publishers with their own challenges, all of us dealing with new technology and changing markets. They need a varied group of working designers willing put time in working closely with them at the planning stage. They are actively looking for people to work with. May 22, 2012 at 9:57
  • Even on the beta, suggestions fly thick and fast but often without specifics that would make them useful. As an engineer or manager, how do you choose which of >1,000 feature requests are more important than other ones? I'm not sure how I would choose, outside of my own workflows. Add considerations of time and available engineering resources, synchronizing with all the other product teams, under-the-hood stuff that's vital but adds nothing to features (like decarbonizing the program for 64-bit Mac Cocoa), and it gets really hairy. May 22, 2012 at 10:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .