OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-adoption message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dita-adoption] Listening Session Items for the Tracking Spreadsheet


Thank you for all your work on this Stan!


I've placed this content into an online Google Sheet. I have already sent invitations to edit this sheet to the active members of this group (namely: Stanley Doherty, Tulika Garg, Robert Thomas, Joseph Storbeck, Chris Goolsby and Scott Hudson). If you are not in this list and would like access, please send me an email!


I also added additional columns so that we can sort them by: DITA 2.0?, Adoption White Paper?, or Any Action? (plus a Notes field). I think we can start making our way through this during Monday's meeting.


Cheers!

 

-

Keith Schengili-Roberts
Market Researcher and DITA Evangelist
 
IXIASOFT 
825 Querbes, Suite 200, Montréal, Québec, Canada, H2V 3X1
tel  + 1 514 279-4942  /  toll free + 1 877 279-4942 



From: dita-adoption@lists.oasis-open.org <dita-adoption@lists.oasis-open.org> on behalf of Dr. Stanley Doherty <stan@modularwriting.com>
Sent: Thursday, February 23, 2017 9:11:05 AM
To: dita-adoption@lists.oasis-open.org
Subject: [dita-adoption] Listening Session Items for the Tracking Spreadsheet
 
Hi Keith and fellow Adoption folks --

I combed through all the listening session notes and extracted lots of items that could be candidates for tracking in the Google sheet. I did no normalization; if 12 people said that they had an issue, I preserved all 12 comments.

I created the list in Excel and have uploaded the spreadsheet to Kavi. The following flat list has the same information sorted by keyword.

Keith -- hopefully doing this is a spreadsheet will help you moving what you want into Google Sheets.

Enjoy
Stan


Agile: Works in an Agile environment. (PegaSystems / Cambridge)
Business / ROI: What are some of the best strategies for selling senior management on DITA? (Fidelity Investments / Cambridge)
Business / ROI: What detailed examples or use cases best demonstrate the overall ROI? (Fidelity Investments / Cambridge)
Business / ROI: Will never have time to do work and build a complex business case for DITA. Need help! (HPE (Vertica) / Littleton)
Business / ROI: What specifically is the ROI for moving from on version of DITA to another? (VMware / Cambridge)
Business / ROI: New DITA features like keyrefs need to be related to use cases and business value. (VMware / Cambridge)
CCMS: CMS and editor upgrades are painful. (FICO / San Jose)
CCMS: CCMS does not support DITA 1.3. (NxStage / Littleton)
CCMS: CMS is difficult to use. (VMware / San Jose)
Change management: How can we get more information about change management? (Akamai / Cambridge)
Change management: How do we get more "buy-in" from writers during a migration? (Fidelity Investments / Cambridge)
Change management: Moving people from Framemaker to DITA continues to be a challenge. (Jeppesen / Denver)
Change management: Dealing with writer push-back about tagging. (KLA-Tencore / San Jose)
Change management: In addition to technical training, supporting people as they learn to rethink the writing process is critical. (Oracle / Denver)
Change management: Are there case studies or best practices for moving writers new to DITA along the path more quickly? (Oracle / Denver)
Change management: Need persuasive data/advice about moving Framemaker fans to consider DITA.  (Schneider-Electric / Littleton)
Change management: Moving the team to something as formal/rigid as DITA was tough; would prefer a less formal step along the way.  (Turumo BCT / Denver)
Change management: Moving writers to topic-based authoring was more of a challenge than expected.  (Xilinx / Denver)
Chunking: Where do I learn about best practices with chunking? Valuable but confusing. (AIR Worldwide / Cambridge)
CMS: DITA integration is too dependent on CMS vendors. (Tibco / San Jose)
Content management: CMS options and strategy across divisions is a challenge. (Jeppeson / Seattle)
Content management: Additional writing and/or support for groups NOT in a CCMS would help them assess the ROI of a CCMS. (ServiceNow / Kirkland)
Content reuse: Difficult when working with lots if legacy content coded to an earlier version of DITA. (IBM / Littleton)
Content reuse: Content reuse is a key driver in selling upper management. Difficult to measure cross product lines. (PegaSystems / Cambridge)
Content reuse: DITA reuse is optimized for confined deliverables, not for multiple products or deliverable types.  (Progress Software / Littleton)
Content reuse: Need guidelines/whitepapers about reuse strategies (calculating reuse). (Progress Software / Littleton)
Content reuse: Need guidelines/whitepapers about updating legacy sources (reuse without cloning). (Progress Software / Littleton)
DITA features: Would like to see more discussion/development about string-based, conversational content. (Amazon / Seattle)
DITA features: Would like to see more associative metadata, something that can be applied to content after processing.  (Amazon / Seattle)
DITA features: DITA "topics" are too heavy-weight for developing content to used interactively/conversationally. (Amazon / Seattle)
DITA features: Code blocks need to support syntax highlighting.  (Amazon / Seattle)
DITA features: Need some support for personalizing content IN a product. (AutoDesk / Littleton)
DITA features: Stylesheets are expensive. (Brocade / San Jose)
DITA features: Exchanging/integrating DITA metadata with Adobe Experience Manager is a challenge. (Brocade / San Jose)
DITA features: Has the perception that DITA has fallen behind other publishing frameworks available to companies.  (F5 Networks / Seattle)
DITA features: DITA not moving fast enough. (F5 Networks / Seattle)
DITA features: Need better support in DITA 2.0 for documents code (APIs). (F5 Networks / Seattle)
DITA features: How can we reuse DITA content in a social-media world? (FICO / San Jose)
DITA features: Want an element that can be used as a variable anywhere, more flexible than <ph>. (HPE / San Jose)
DITA features: Wants a JSON output transform to be able to integrate with Swagger and other modern frameworks. (IBM / Littleton)
DITA features: Some groups have abandoned DITA - back to Word to share information outside the silo.  (IBM / Littleton)
DITA features: Need more documentation on hoe to do specializations. (Intel Programmable Solutions / San Jose)
DITA features: DITA contraints are not easy to work with. (Jeppesen / Denver)
DITA features: DITA elements to document software (APIs) are not robust, out of step with software concepts in the industry.  (Jeppesen / Denver)
DITA features: Example of API element immaturity; look at <apiname> being overloaded.  (Jeppesen / Denver)
DITA features: DITA models for documenting workflows with decision trees (multiple paths) is weak.  (Landmark/Halliburton / Denver)
DITA features: Would like to see best-practice documents from practitioners in the field. (Micro Motion / Denver)
DITA features: Would like to see a best-practice document on constraints. (Micro Motion / Denver)
DITA features: Would like to network more with other DITA people working in medi al devices. (NxStage / Littleton)
DITA features: Enormous DITAVAL files with hundreds of conditions can be challenging; fragile. (Oracle / Littleton)
DITA features: Wants to flag an entire topic, not just blocks within a topic.  (Oracle / Littleton)
DITA features: Some things (formal tasks) are so deeply typed, they present conceptual problems. Necessary? (Oracle / Littleton)
DITA features: Need more discussion about embedded user assistance generated from DITA. (Oracle / Littleton)
DITA features: Topic-level reuse can be challenging. Easier to reuse at the in-topic element level.  (Paccar / Seattle)
DITA features: Have groups in Europe and India authoring in Markdown and HTML; not sure how to collaborate. (Progress Software / Littleton)
DITA features: Need embedded media recommendations. (Ring Central / San Jose)
DITA features: Cross-bundle linking is difficult; need to explore DITA 1.3 support. (ServiceNow / Kirkland)
DITA features: DITA metadata does not seem to be related to search engine optimization (SEO). Go outside DITA? (ServiceNow / Kirkland)
DITA features: Should add <othermeta> to block elements outside the topic <prolog>. (ServiceNow / Kirkland)
DITA features: Need metadata to support enhanced personalization. (ServiceNow / Kirkland)
DITA features: Need more information on how to do workflows in DITA. (Tibco / San Jose)
DITA features: Best practices around branding documentation in DITA to avoid hard-wired names would be good. (Turumo BCT / Denver)
DITA features: Want to see a "super-task" ("meta-task") standard within DITA. (VCE / Littleton)
DITA features: Interested in dynamic (interactive) maps that can poll information and branch processing accordingly. (VCE / Littleton)
DITA features: Would like to see a rapid prototyping toolkit; want to be nimble in creating specializations. (VCE / Littleton)
DITA features: Need to bring more of the product development community into the document development process. (VMware / Littleton)
DITA features: Features developed by the TC (in spec) are not addressing the problems faced by DITA groups in the field.  (VMware / Littleton)
DITA features: Features not responding to competitive offerings - evolutionary pressure working against DITA. (VMware / Littleton)
DITA features: Need compelling use case about using DITA and Markdown in the same pipeline. Need ammunition. (VMware / Littleton)
DITA features: Need better semantic markup for API documentation -- class, method, function, macros, libraries). (Wind River / San Jose)
DITA features: Specializations are difficult; must be an easier way.  (Xilinx / Denver)
DITA future: DITA needs to evolve; needs to work with open source tools like hopscotch (product tours). (IBM / Littleton)
DITA futures: If the next version of DITA takes five years, the team would most likely have moved on to something else.  (AutoDesk / Littleton)
DITA futures: One group has been told that Confluence is the tool for Agile development; not DITA. They are moving.  (Schneider-Electric / Littleton)
DITA futures: Need to release DITA in smaller, more Agile increments.  (VMware / Littleton)
DITA maturation model: Can we get details (nuts-n-bolts) about the maturation model? (Akamai / Cambridge)
DITA pilots: Conducting DITA pilots and hiring DITA-experienced writers. (PegaSystems / Cambridge)
DITA spec: More use cases and examples would be helpful. (Brocade / San Jose)
DITA spec: Need more holistic examples.  (Guidewire / San Jose)
DITA spec: Spec needs to be more accessible, too difficult to drill down and to get needed information. (Intel Programmable Solutions / San Jose)
DITA spec: Need better examples in the spec.  (Intel Programmable Solutions / San Jose)
DITA spec: Need better examples in the spec. (Intuitive Surgical / San Jose)
DITA spec: Would like a searchable version of the spec.  (Intuitive Surgical / San Jose)
DITA spec: Not seeing top-notch technical writing in the spec. (Jeppesen / Denver)
DITA spec: Must develop internal DITA specs to compensdate for lack of clarity and good examples in the spec. (Jeppesen / Denver)
DITA spec: The spec needs more complex examples, ones that do not dwell on obvious/easy stuff. (VMware / Cambridge)
DITA spec: The examples are not realistic, too simplistic for teams deploying features with complex content. (VMware / Littleton)
DITA spec: Need examples and use cases directed toward multiple audiences (technical, managerial, financial). (VMware / Littleton)
DITA tools: Support for a running content diff.  (Paccar / Seattle)
Management: Training wants less structure, a la Powerpoint or Word. (Applied Materials / San Jose)
Management: Need to get service engineers involved in developing and sharing content. (Applied Materials / San Jose)
Management: Allocating DITA experts on a team to DITA training is expensive; takes them away from making DITA work. (F5 Networks / Seattle)
Management: Doing "standard" DITA demos to Training groups only convinces them to stay away from DITA. (F5 Networks / Seattle)
Management: Groups using HTML and Markdown have bypassed the DITA doc group. Can't bring them back. (F5 Networks / Seattle)
Management: Getting new writers up to speed quickly is a challenge. (FICO / San Jose)
Management: Exchanging content with Training is needed, but a tough sell. (Guidewire / San Jose)
Management: Need to define the key use cases for DITA ROI and sell those to senior management. Stay focused. (Jeppeson / Seattle)
Management: Recruiting DITA-trained writers is a challenge. (KLA-Tencore / San Jose)
Management: High turnover in DITA-trained staff in India; need to shorten the training/rampup cycle for DITA writers. (Landmark/Halliburton / Denver)
Management: Publishing a list of DITA training resources (especially) videos would be a BIG help.  (Landmark/Halliburton / Denver)
Management: Best practices around managing stylesheets across divisions in a company would be useful. (Micro Motion / Denver)
Management: What are the right steps to move the migration along, keep it moving? (NANTHealth / Cambridge)
Management: How do we retain great writers who have lost the "pleasure" of shipping beautiful documents? (Oracle / Littleton)
Management: Hiring or grooming a DITA tools person is a huge challenge.  (Oracle / Denver)
Management: Recruiting DITA-training writers is difficult. (Paccar / Seattle)
Management: Recruiting DITA-competent IAs and tools people is difficult. (Paccar / Seattle)
Management: Tech writing (DITA and non-DITA) feels bring, stuck. Difficult to attract young writers. (Progress Software / Littleton)
Management: Hiring experienced DITA writers as "DITA Captains" helped everyone. (VMware / Cambridge)
Management: Need compelling information/support to respond to arguments that groups move out of DITA. (VMware / Littleton)
Management: Re-orgs between divisions gave teams permission to leave DITA and go back to Framemaker.  (Xilinx / Denver)
Migration: Are there best practices for conversions/migrations -- piecemeal? all at once? (AIR Worldwide / Cambridge)
Migration: Are there templates or models for planning a conversion? (AIR Worldwide / Cambridge)
Migration: When companies migrate to DITA via "hops" (phases), what typically are those "hops"? (Akamai / Cambridge)
Migration: Writers new to DITA are simply overwhelmed. (Applied Materials / San Jose)
Migration: Doing all the conversions in-house has been expensive and difficult. (Guidewire / San Jose)
Migration: Need guidance on pre-conversion content prep. (Guidewire / San Jose)
Migration: Conversion strategies -- incremental (US) or all-at-once (Japan). (Hitachi Data Systems / San Jose)
Migration: Want migration tips and techniques.  (HPE / San Jose)
Migration: Want advice or best practices on some elements, e.g. reference properties; still used? avoid? (HPE / San Jose)
Migration: Working in MadCap Flare; encountering limitations motivating the consideration of DITA. (HPE (Vertica) / Littleton)
Migration: Conversion from Frame/RoboHelp was excruciating, even with excellent help from a vendor.  (Intel Programmable Solutions / San Jose)
Migration: Post-conversion cleanup took a long time.  (Intel Programmable Solutions / San Jose)
Migration: Conversion costs are high.  (Intuitive Surgical / San Jose)
Migration: What are best practices in migrating from MadCap Flare to DITA? (NANTHealth / Cambridge)
Migration: Moving from MadCap Flare to DITA; prepping content in Flare as though it were DITA. (PegaSystems / Cambridge)
Migration: Need business cases. (Ring Central / San Jose)
Migration: Need implementation strategy/recommendations. (Ring Central / San Jose)
Migration: Need more DITA resources in general.  (Ring Central / San Jose)
Migration: Moving teams to DITA from different tools is not one process. Each pathway has different challenges. (Rocket Software / Denver)
Migration: Looking for migration best practices. (Sigma Tech / Ericsson / San Jose)
Migration: Worked through the information model before choosing a tool to author the information. (Wind River / San Jose)
Organization: Each business unit has its own CMS strategy. (Applied Materials / San Jose)
Organization: Centralizing DITA functions creates problems for de-centralized groups trying to leverage DITA locally. (AutoDesk / Littleton)
Organization: Centralized tool/transforms group works well in general; doing renegade transforms helps. (IBM / Littleton)
Organization: Having teams working on different tools (DITA, Frame) makes finding common ground difficult. (Oracle / Littleton)
Reltables: Relationship tables are hateful; they use only siyrce-to-target. (Oracle / Cambridge)
Silos: How do we break down silos around DITA? (Akamai / Cambridge)
Silos: Concerned about DITA being silo'd in Tech Pubs - not able to break out. (AutoDesk / Littleton)
Silos: Not seeing DITA move outside tech pubs; concerned that it may be a career-limiting technology now. (VCE / Littleton)
Transforms: Use in-house tools to publish online help.  (Amazon / Seattle)
Transforms: Developing bridges/workarounds between DITA and all the third-party tools used in Engineering is expensive. (Amazon / Seattle)
Transforms: Corporate defines "look and feel" style; difficult to implement sometimes in DITA. (Applied Materials / San Jose)
Transforms: Central tools group can take a VERY long time to respond to formatting requests. (AutoDesk / Littleton)
Transforms: The difficulty involved with updating transforms is an impediment to building workflows. (AutoDesk / Littleton)
Transforms: Lack of a round-trip Confluence plug-in isolates content developed by the DITA group.  (F5 Networks / Seattle)
Transforms: Learning XSL and XSL:FO is a real challenge. (FICO / San Jose)
Transforms: Plug-in customization is the most challenging aspect of DITA.  (Jeppesen / Denver)
Transforms: PDF customization and delivery is painful; WebHelp is good.  (Jeppesen / Denver)
Transforms: Difficult to branch out beyond PDFs - expensive and tangled up in regulatory specs. (NxStage / Littleton)
Transforms: Customizing PDF is expensive. (Oracle / Cambridge)
Transforms: Online help from XML is dying; supplanted by web frameworks and feature-rich delivery. (Oracle / Littleton)
Transforms: Need a GUI to manage customizing transfomations (a la RoboHelp). (Oracle / Littleton)
Transforms: DITA-OT error messages are difficult to parse (interpret).  (Oracle / Denver)
Transforms: Need output configurations to support layout-intensive or graphics-intensive pubs.  (Ring Central / San Jose)
Transforms: Maintaining in-house transforms is expensive.  (Rocket Software / Denver)
Transforms: Lack of a DITA-to-Confluence transform prevents DITA people from demonstrating collaboration/Agile. (Schneider-Electric / Littleton)
Transforms: Lack of a DITA-to-Confluence transform means maintaining parallel DITA and Confluence sources for shared content. (Schneider-Electric / Littleton)
Transforms: Getting the PDF transforms working was a challenge. (Turumo BCT / Denver)
Transforms: Updating stylesheets constantly is expensive.  (Turumo BCT / Denver)
Transforms: Want a tool that makes customizing transforms easier. (VCE / Littleton)
Transforms: Engineers write in Markdown and develop their own puboicationsin gitbook. Duplication of effort.  (VMware / Littleton)
Transforms: Updating DITA-OT transforms is difficult. (Wind River / San Jose)
Translation: Saw 30-40% translation savings; other groups got 70%. How do we measure savings? (Guidewire / San Jose)
Translation: Has done some interesting things with crowd sourcing translation.  (Schneider-Electric / Littleton)
Vendor management: What are the right questions that I need to ask different vendors? (NANTHealth / Cambridge)
Vendor management: Would like to know what questions to ask vendors to determine ROI in upgrading to DITA 1.3. (VMware / Cambridge)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]