Integrating hat content into mobile app lavacon
Download as PPT, PDF1 like1,038 views
Neil Perlin, an expert content consultant, discusses strategies for converting technical help content to mobile applications, emphasizing the importance of understanding various mobile app types and the potential dangers of miscommunication regarding terminology. He outlines a detailed process for content conversion, highlighting the necessity of evaluating content suitability for mobile environments and implementing a robust content strategy. Perlin also offers practical guidance on using tools like Viziapps for content import and managing graphic resources in mobile applications.
Integrating hat content into mobile app lavacon
- 1. Pulling HA Co nte nt T I N tive A p s nto a p
- 2. Who Am I? Neil Perlin - Hyper/Word Services. – Internationally recognized content consultant. – Help clients create effective, efficient, flexible content in anything from hard-copy to mobile. – STC’s lead W3C rep – ’02 – ‘05. – Certified – Flare, Mimic, Viziapps, RoboHelp in process of renewal.
- 3. The Issue Fairly easy to single source HAT content to mobile – to a web app. But can we feed HAT content to a native app – use Flare, RH, or others as content portals to native apps? In other words, extend help single sourcing to “true” mobile?
- 4. Contents Overview of “Mobile” Help vs. Mobile – Design Differences Help-to-Mobile – Content Conversion
- 6. Basic Terminology App – Short for application, usually used now re mobile devices – “iPhone app”. – Highly focused – “micro-tasking” – compared to PC-style applications. » Native apps – Follow a specific platform standard, can run on-device resources – e.g. iPhone app. » Web apps – Run in a browser on any device but can’t run on-device resources, may be mobile- optimized – e.g. WebHelp vs. WebHelp Mobile. » Hybrid – Mix of native and web – “next big thing”. Based on HTML5 and CSS3.
- 7. Why Terminology Matters Affects choice of hardware and software- related delivery “mechanisms”. Terminology mixups can spell disaster. – Just saying “mobile” is an invitation to buy the wrong tools or hire the wrong developer. – Like not being clear about WebHelp vs. Web Help or HTML help vs. HTML Help.
- 8. Authoring Tools In tech comm… – Flare 6+ – Web apps, ebooks. – RoboHelp 8+ – Web apps, ebooks, native apps with some content and vendor-approval issues. Outside tech comm… – ViziApps – IMO, offers the best data handling of any tool in this space. » I’m also certified in it... – Others like appmakr, IBuildApp, Google App Inventor, appMobi, etc.
- 9. Why Use GUI Tools? You may know the tool, so you only have to learn a few new features. Keep you out of the code. Set technical boundaries for you.
- 10. Plan To… Develop a content strategy, standards: – A few high-level suggestions: » Define how mobile effort solves business problem. » Define your terms. » Identify the content sources, how to support them. » Implement a consistent tool set in the company. » Support those tools with templates and training! » Select external/internal standards and adherence. » Think inside the box – no tool hacks.
- 11. Help vs. Mobile – Design Differences Affecting Data Conversion
- 12. Text-Heaviness Help usually text-heavy, apps not.
- 13. Text-Heaviness Though there are exceptions, sort of…
- 14. Control Types and Locations Usually at top and left in help…
- 15. Control Types and Locations But at bottom in apps – less dangerously tappable…
- 16. Orientation Landscape in help, portrait in apps (unless screen rotation enabled)
- 17. Design Conclusions Help converted to mobile is unlikely to look like an app. Must plan for mobile before starting a help project whose outputs include acting as a data portal to an app. More than just outputting a help project to “mobile”. Given these issues, how do we get HAT content into an app?
- 18. Help to Mobile – Content Conversion
- 19. High-Level Considerations What must be done to the content? Where? – Is the HAT content the app or is it feeding into an app? » HAT content is the app, you have RH10 or Flare 8 – use the HTML5 or mobile outputs. » HAT content is the app, you have another HAT – keep going. » HAT content is feeding an app – keep going. – Then…
- 20. High-Level Considerations – Do general clean-up: » Convert SWFs to MP4 or HTML5 for iOS. » Replace fixed CSS size units with variable. » Evaluate if resized images still work – if not, can we remove them – if so, what effect on content? » Evaluate meshing of HAT and app dev tool. – Conditionalize the content to isolate the app- applicable content. – Get app-applicable content into app database – how?
- 21. Content Import Details The following discussion uses ViziApps Studio (www.viziapps.com). – Supports use of web services, SQL databases, and Google Docs/Drive as app databases. – Principles should be portable to other such tools.
- 22. Content Import Options We can either: – Copy and paste the content by hand from our HAT to the database. – Export conditionalized output to WebHelp or HTML5, then import the HTM files to Google Docs/Drive’s spreadsheet. » But there’s no inherent structure for the import. » Lots of HTM files… – Export conditionalized output to Word, then import into Google Docs/Drive’s spreadsheet. » Better since it has structure, one file...
- 23. The Process Looks complex but is surprisingly simple: 1. Create HAT template that mirrors structure of DB with hard returns after each template field and build tags as needed. 2. Create the topics using HAT template. 3. Output to Word. 4. Save as “web page, filtered” to remove excess Word codes, then rename as <file>_filtered.
- 24. The Process … 5. Select all and convert to table, using as many columns as in DB, select autofit to content and separate text at paragraphs. 6. Save, then close Word. 7. Open in Excel, save as CSV (MS-DOS), and rename as <file>_csv. 8. Open GDocs spreadsheet worksheet.
- 25. The Process … 9. Put pointer on 1st cell of 1st blank row where you want to start inserting the imported content. 10.Select File>Import, select the file, select Append Rows to Current Sheet, the Automatic separator character, and go.
- 26. Example – Starting Point
- 27. New Content In Flare Showing build tags.
- 28. In Word Output to Word, saved as “web page, filtered” with hard returns after each field, and converted to a table.
- 29. In Excel Saved as CSV (MS-DOS).
- 30. Setting Up In GDocs The File Import dialog box settings.
- 31. Added to the Database In the GDocs spreadsheet.
- 32. And In the App
- 33. What About Graphics? Like this in the HAT content…
- 34. …Graphics? Not directly through an import because the GDocs database doesn’t store the image directly. Instead, image is uploaded to the cloud via Amazon S3, and the database stores the image URL – e.g. it’s a different process.
- 35. Tables? Here’s the progression…
- 36. Tables? … the progression…
- 37. Initial Assessment What will work: – Text – Flows to meet the screen size. – Variables – Because they’re text-only. What will cause trouble: – Need to trim info. – Items that are too wide or big: – Items that use different controls in mobile vs. in a HAT – images, tables (lists in mobile), links.
- 38. Initial Assessment …will cause trouble: – Items with no equivalent controls in mobile, like Flare togglers. – SWFs – Must be inserted as images to get URL to Amazon S3. – Snippets – Anything other than text will break.
- 39. Conclusions Using a HAT as a data portal to an app will work with small amounts of text with no formatting. Anything else is iffy – may not convert. – Or may not mesh with the associated object in the app – e.g. use of image field to insert image rather than inserting it in a text paragraph. Test and plan before you start…
- 40. Hyper/Word Services Offers… Training • Consulting • Development Flare • RoboHelp Viziapps • Flare/RoboHelp Mobile XML Single sourcing • Structured authoring
- 41. Thank you... Questions? Hyper/ ord S W ervices 978-657-5464 nperlin@concentric.net www.hyperword.com