ViziApps Studio’ Logic Builder(TM) – the Continued GUI-izing of Authoring

Authoring tools for new technologies typically start code-heavy but follow the same trajectory over time – tasks that required working in the code can now be handled through a point-and-click GUI. The result?

• Less technical authors can create outputs nearly as powerful as those by more technical authors, so the market expands. (The first online help conference I attended, in 1991, before GUI tools like RoboHelp and Doc-to-Help made an impact of the market, was attended by every online help author that the organizers could find in North America. There were 12 of us. In 1994, after GUI tools had appeared, I gave a speech on help authoring to the STC’s Boston chapter. There were over 100 attendees.)
• Technically-oriented authors, and programmers, can create outputs faster because the GUI simplifies tasks like interface design. Authors can still do these tasks in code if they want to, but they don’t have to.

My example comes from online help, but it applies to another technology that technical communicators can get involved – app development. Technical communicators often don’t see themselves as creating apps, but we didn’t see ourselves as creating online help and web pages in the early 1990s either.

Technical communicators have shied away from apps because of the technical skills required. But just as with online help and the web, new app development tools hide the code behind a friendly GUI, making it more inviting to step into this space. An entire set of app development tools known as “low code/no code”, DIY (Do IT Yourself), or RMAD (Rapid Mobile App Development) tools has appeared in the last few years. (Look for a post about these tools in the near future.)

In this post, I’ll present an example of such GUI-izing in an RMAD tool called ViziApps Studio – www.viziapps.com. (Note – I’m certified in and provide training and development support for Studio.) Studio offers a full suite of predefined actions that you can use to complete a mobile app. Some are simple menu picks, like creating a button that can jump to a specific page in the app. Others support bar code scanning and enable maps and geo-location services. In many cases, these predefined actions may be all you need for your app.

But what if you need more advanced actions that are not predefined. These require JavaScript. The Studio makes it easy to add JavaScript to an app, but you have to know JavaScript in the first place. What if you don’t? That’s where ViziApps’ Logic Builder comes in.

Here's a screen shot of Studio’s old actions dialog box:

It looks straightforward. To jump the user to the previous page, apply that action. To jump the user to a different page, select “Go to page” and specify the name of the target page. No Javascripting.

But what if you want to add a button that, when clicked, clears all entries in all fields on a page? There’s no predefined control for that so you have to write the JavaScript and attach it to the button. Or if you want to perform some arithmetic, like calculating the discount on an invoice? Again, there’s no predefined action for that so you have to, again, write the JavaScript and attach it to the button.

That’s where Logic Builder comes in. Logic Builder lets you add the predefined actions – those that don’t require JavaScript and many of those that do. Here’s the main Logic Builder screen.

Let’s say you want to add a “clear all fields on this page” action to a button. Select the Field Action options. Here’s the result. (The next three images extend off the right hand side of the page. It was the only way to make them large enough to read the screen content.)

Now select the “Clear all the fields on the current page” option. Here’s the result.

Need to specify which page to clear? Select the “Clear all the fields on a page” option and specify the name of the page from a pulldown. No Javascripting.

Want to perform an arithmetic operation? Select Math and Arithmetic Operation. Here’s the result where you can define the operation. Again, no Javascripting.

Will Logic Builder eliminate Javascripting in a project? It depends what you want to do. But Logic Builder will eliminate a lot of it, perhaps all of it. Things may get a bit complicated when you specify field values for some actions – e.g. what’s an array? Or an If-Then-Else? But many business apps may not need these features. If yours does, there’s reference material and training available.

Logic Builder offers many other actions, including:

• Navigation – to move around an app.
• Data management – to retrieve data from or write it to a database.
• Device action – such as making a call or taking a photo.
• Popups – to link to a web page or display an alert.
• Dates and times – to retrieve dates or parts of dates or times.
• Logic – to perform tests on data and take different actions depending on the results.
• Math – to perform mathematical calculations.
• And more.

Each category can be expanded to include new actions, so this feature is extensible to meet future Javascripting needs.

The appearance of Logic Builder and similar GUI authoring features are making it easier for technical communicators to create powerful business apps. App development can become one more skill in your skill set.

NOTE: Logic Builder is in a limited beta release as of February 5, 2018. I’ll post a note when it becomes fully available. 

Logic Builder is a trademark of ViziApps, Inc.

Inexpensive Usability Testing

(Excerpted from my forthcoming book “Writing Effective Online Content Project Specifications”)

We rarely think of doing usability testing for online help or documentation (online content) because, after all, it’s just text. In fact, online content is text, but software forms a big part of it in the navigation, retrievability, and other features. And like any software, it should be reviewed for usability.

What if no group in your company does formal usability testing? Can you do it yourself without spending a lot of money? Yes. The results won’t be statistically significant but they will be useful and inexpensive. How to do this? In brief…

·         Create a prototype of your online content project. It can be a small but fully functional online output or a paper prototype. (If you’re not familiar with paper prototyping, see Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces by Carolyn Snyder, published in 2003 and available on Amazon. The book is an excellent introduction to the subject, with additional points on usability in general.)

·         Create several little scenarios with questions whose answers can be found in the prototype. For example, “How many types of fixed asset depreciation are there?” or “What is the specific gravity of tungsten?”

·         Find a small but representative group of test subjects. If you’re testing a product for a general audience, you might set up your test in a conference room and invite people in at random to be test subjects. If your company runs a user conference, that’s also a good place to find subjects.

·         Tell the subjects that you need just fifteen minutes of their time. Offer a small gift (sometimes called swag or “tchotchkes”) as an inducement for them to help. (No pens or coffee cups – both badly overused.) For more impact, tell the subjects you’ll enter them in a raffle for dinner for two at a local restaurant.

·         Give the subjects the scenarios and ask them to find the answers. Watch them but don’t say anything or offer any help. You can tell them to follow the so-called “speak aloud protocol” where they’re free to say what they’re thinking. This may be a bit uncomfortable to hear but it’s the feedback that you want.

      The object is to see if the subjects can navigate through the online content to find the answers to the questions posed in the scenarios and how difficult and frustrating the process was. The results won’t be statistically significant, but may well be very enlightening. That’s what you want.

Beyond the Bleeding Edge Returns

Beyond the Bleeding Edge was a conference session that I ran at the STC’s summit from 1999 until 2014, and a column I wrote for the STC’s Intercom magazine from 2000 to 2015. The goal was to introduce technologies that were new to tech comm – on the leading (or bleeding) edge and beyond – such as XHTML, WSDL, JavaHelp, haptic interfaces, the W3C RDF metadata standard, and more.

The Bleeding Edge is now Hyper/Word Services’ technology blog. Look for a new post every 3-4 weeks on various technologies, tools, and methodologies, with a focus on mobile content and the Information 4.0 concept, plus whatever else seems appropriate.

Technology is fun!

Farewell to “Beyond the Bleeding Edge”

The Bleeding Edge was a series of presentations at the annual STC conference (now the Summit). Its goal was to address cutting-edge technologies and methodologies that emerged too close to the conference to be addressed by the standard presentation proposal route. I proposed it after the 1998 conference after hearing comments that there weren’t enough advanced sessions. After approval by then STC-president Mark Hannigan and Assistant to the President Deborah Sauer, I launched the Bleeding Edge in 1999. I ran it from 1999 to 2014 except for a two year hiatus due to some organizational issues in 2008 and 2009.

Bleeding Edge presentations covered JavaHelp coding, XHTML, haptic interfaces (IBM sent a speaker from London, as I recall), the W3C RDF metadata standard, search engine optimization, XSLT, on-demand publishing, and similar topics. My Beyond the Bleeding Edge column in STC Intercom came out of the Bleeding Edge. The Bleeding Edge also spun off a “standards watch” session, with speakers discussing developments in bodies like the W3C and IEEE, and several “standards watch” columns in Intercom.

The Summit organizers decided not to run the Bleeding Edge in 2015 because they thought the Summit’s technical level had risen to the point where the Bleeding Edge was no longer needed. From what I saw of the presentations in Columbus, I agree. Although I’ll miss the Bleeding Edge, its demise is a positive sign for the Summit overall.

My thanks again to Mark Hannigan and Deborah Sauer, and to all the presenters over the years who did such an outstanding job of helping keep STC on the cutting (or “bleeding”) edge.

Adobe RoboHelp 11 – A Review

RoboHelp was one of the first HATs (help authoring tools) and has long had a big part in molding today’s online help and content world. Adobe acquired RoboHelp in 2005 as part of its purchase of Macromedia and has been extending it since then, starting with v. 6 in 2007 and continuing through v. 11, released on January 14, 2014.

In this review, I’ll focus on what I consider to be the most significant features of RoboHelp 11 and what they say about trends in tech comm. There are two, enhanced support for responsive design as part of HTML5 publishing, and the cloud-based collaboration added to the Resource Manager.

HTML5 Publishing and Responsive Design

I’ll start with a quick overview of HTML5 and responsive design if you’re not familiar with the terms.

HTML5 Concepts

HTML5 is the successor to XML and earlier versions of HTML. It’s both a coding language and an output format. RoboHelp 11 still uses XHTML, introduced in v. 8, as the native coding environment, but added HTML5 as a browser-based output format in v. 10 and extended it in v. 11. You can still use WebHelp for browser-based outputs, but HTML5 has several benefits that make it worth looking at as a replacement for WebHelp, including:

·        Searchability by web crawlers. The WebHelp output format has met our needs for years but has a problem that didn’t manifest itself until web search crawlers came into use. WebHelp uses “framesets” to controls layout, but framesets block web crawlers from going beyond the home page in browser-based help. The result is that the online help that you write and distribute as WebHelp won’t be found by a crawler and won’t appear in the list of hits from a Google search. In other words, users can’t find your content through Google. This may not matter if the content is behind a firewall or login and only available to customers. But if your company is adopting a more public-facing strategy, this can be a strategic limitation. HTML5 fixes that limitation.

·        Support for CSS3. This extension of the CSS (Cascading Style Sheet) 2 standard gives more power and flexibility for formatting under modern browsers.

·        Support for a new type of mobile apps called “hybrid apps” that are based, in part, on HTML5. RoboHelp doesn’t output hybrid apps, but the HTML5 code that it does output forms part of the foundation for those apps. In other words, HTML5 output is a step toward hybrid apps.

Responsive Design Concepts

The idea for responsive design arose as more and more devices with different screen sizes, resolutions, and other properties appeared on the market. We can optimize our outputs for one or two devices, but it quickly becomes technically difficult and cost-prohibitive to optimize our outputs for every device on which they might appear. The emerging answer is “responsive design”.

Responsive design says that content can automatically change its design based on the properties of the device on which it’s displayed – e.g. it’s device-agnostic. For example, HTML5 output from a project can change its design depending on whether it’s displayed on a PC, tablet, or smartphone. (The image below shows how content might reformat itself based on the device. The three images look the same at first glance, but note how the Greek temple, the Adobe icon, and the controls move or disappear depending on the output. Automatically…)

RoboHelp’s Support for HTML5 Output and Responsive Design

RoboHelp 10 supported what Adobe called “Multiscreen HTML5” – basically responsive design. It used “screen profiles” (to specify different screen resolutions that controlled the redesign), “screen layouts” (to design the page types and customize them for the different resolutions, and CSS “media queries” (to define the specifics of the page format for each resolution set through the screen profiles). This mix of features let you automatically change the design of the output and, by using conditional build tags, change the content itself depending on the device. It was a good start, but there were two issues.

·        Some of the concepts, particularly CSS media queries, were new to many users.

·        Some of the work, especially screen layout design, was complex and could be time-consuming.

RoboHelp 11 goes a long way toward addressing both issues by adding a new output type, Responsive HTML5. Responsive HTML5 is a streamlined version of Multiscreen HTML5 that uses predefined layouts for different screen sizes and properties. In other words, much of the setup work has been done for you. If you do want to customize a layout, the process is semi-wizard-driven. To contrast the two approaches, the image below shows the layout editor for the Topic page type in Multiscreen HTML5.

 

There’s a lot of power available in the toolbar but you have to know what you’re doing. In contrast, the image below shows the layout customization editor for a layout, in this case the Theme2_Government layout, for the Responsive HTML5.

The many screens prompts make it easy to see what screen object you’re changing and the options are clearly labeled in the Properties pane. So customization will be fairly straightforward, hopefully tasteful as well. And Adobe has a link to a layout gallery which currently lists two predefined themes, with more sure to come, so you won’t have to start creating yours from scratch.

So Responsive HTML5 is easier than Multiscreen HTML5 but less customizable. The main difference is that Multiscreen HTML5 lets you use conditional build tags to vary the content for individual devices while Responsive HTML5 lets you use conditional build tags but applies the same build tagged content for all devices. This should be a minor point if you want to output the same content to all devices, but may affect your planning if you literally want different content output to a tablet versus a smartphone.

If all this sounds confusing, here’s a simple summary. If you want to output a project using responsive design, open the project in RoboHelp 11, select Responsive HTML5 output in the Single Source Layouts pod, select the desired layout on the General tab, and generate. When RoboHelp finishes generating, click the View Result button (and allow blocked content if you use IE). The output displays in a browser window. Now grab a corner of the browser window and start reducing its size. Once you get to certain sizes – think tablet and smartphone – you’ll see the format change automatically. You’ll have to think about the actual design but the sheer mechanics are impressively simple. And it’s just neat to watch.

Cloud-Based Collaboration via Resource Manager

I’ll start off with a quick overview of the Resource Manager if you’re not familiar with this feature.

Adobe added the Resource Manager several versions ago as a way to share files between projects. For example, let’s say you want to use the same CSS in two projects. The old approach was to find the desired file in the “master” project’s folder in Windows Explorer and copy it to the other project. This worked, but you were doing the file “sharing” manually, outside RoboHelp, so it was easy to paste the copy of the file-to-be-shared in the wrong folder.

The Resource Manager eliminates this problem. You’re sharing the files in RoboHelp under RoboHelp’s control, so they’ll automatically be put in the correct folder. 

The one thing missing in this scenario was file sharing via the cloud. RoboHelp 11 fixes this by letting you set up a shared location using various popular cloud-based services rather than a network drive. You’ll see this option in the Location Type field on the Add Shared Location dialog box that displays when you click on the Add Shared Location icon on the Resource Manager pane, shown in the image below.

You can select from Dropbox, Google Drive, SkyDrive, or others that you might use. When you select one, RoboHelp will find its folder on your PC and fill in the Path field for you. You can also set up subfolders within a service and select just that subfolder. Once set up, you can share topics (new in v. 11 – previous versions didn’t let you share topics) and various control files. If a topic contains embedded elements such as images, RoboHelp will detect their use and carry them over with the topic. (You will have to pull in any snippets separately, but RoboHelp will add them to the topic once you do.) There are also various ways to synchronize changed files.

Overall, the cloud-based collaboration feature is a useful extension of the file sharing concept behind the Resource Manager and a reflection of changes in tech comm.

Other Changes

In addition to the two main features defined above, several others correct problems or omissions. These include:

·        Importing headers and footers when importing a Word document.

·        Defining different headers and footers in different master pages and applying them to different page types in print output.

·        A new color scheme for the interface for greater contrast and readability.

·        SWFs now display and play when included in Word output.

Summary

RoboHelp 11 will be largely familiar and easy to learn for any user of an older version. The biggest new convenience is the addition of cloud-based collaboration, but even that fits into Resource Manager.

The most important new feature, in my opinion, is the addition of the Responsive HTML5 output. Few of my RoboHelp clients need mobile or display-agnosticism yet but every one I’ve spoken with sees it as on the horizon. Responsive HTML5 makes it easy for them to get their feet wet in mobile and should help them ease into the full power of the Multiscreen HTML5 output.

Do you need to upgrade to v. 11? If you don’t need responsive design, cloud-based collaboration, or multiple headers and footers in your print output, probably not. But if mobile or display-agnosticism is on your horizon, RoboHelp 11 is a worthwhile upgrade and a job well-done by Adobe.

 

 

 

 

 

 

Analytics and Tech Comm - Food for Thought?

This post presents a portion of a LinkedIn conversation thread dealing with using analytics, such as Google Analytics, in tech comm. The thread picks up with my request to the original post. (Thanks to Evin Wilkins for starting this whole thing, and Hagay Vider, Matt Sullivan, and Marion Deland for the responses that form the thread.) And with that...

----------------------------------------------

Neil Perlin

President, Hyper/Word Services

… I'm going to be guest-editing an upcoming issue of the STC Intercom magazine with the theme of the bleeding edge. I've got all my topics covered save for one, the use of analytics with regard to tech comm and online help - RoboHelp, Flare, et al. I'm having trouble finding a writer for that topic but I'd hate to omit it. Hagay and Matt and everyone else - do you guys know of anyone who's familiar with analytics and who's used it in a tech comm context?

Hagay Vider

Technical and Marketing Communications Manager at High Security Labs

Neil, if you're looking for content professionals who use Google Analytics, then you should be looking in a different direction. I have used GA for other purposes, not to get usage statistics of technical documentation, but I understand your reasoning. You should look towards other fields for inspiration.

The most common use of GA is to "monetize" content, meaning that web site owners write content that would grab eyes, which justifies charging money to advertise on their sites. This is different than the Wall Street Journal selling subscriptions, and then restricting some content only to paid subscribers. This is free and open content that's paid for by ads.

Technical documentation is not often monetized, since it's usually provided as a type of "customer service" to customers who already bought the product. The only reason I can think of to perform analytics on technical communications is to coordinate with customer service. Where do customers look for information? What information is missing that causes them to open a service call? Should we include this information in the documentation to prevent service calls?

GA is often used for free sites that provide useful information to readers who will follow through with purchasing a product. Such sites include articles on investing, consumer issues, dieting, health and food. These are often the most popular sites, and advertisers know that their readers are ready to make a purchase. The more hits their pages get, the more money they can charge for ad space. Some of the larger sites have a "contact us" page where they sell ad space directly to customers. They provide analytics results as part of the quote. The smaller sites use Google AdSense some other ad space marketing service.

Another group of sites are "news aggregators". They copy news sites on a wholesale basis, and save the content for subscribers who do research, want to dig up require old content and the like. The analytics helps them know which information is in demand. This is much closer to the requirements of technical documentation.

In any case, using GA on your own technical documentation will not create enough traffic to show substantial analytics. You options are to either publish something and get as many of your friends to visit the site, or you can create analytics on different pages in existing popular site, and show how they compare. Visiting your own site often yourself won't work, since the analytics looks for unique IP addresses.

On to the subject for bleeding edge, technical writers sometimes take jobs writing general interest articles and blogs on technical subjects, like software, consumer electronics, medicine, and the like. Sometimes its very technical. This is actually a rapidly growing area within technical/specialized writing.

I previously wrote articles and blogs for an electronics company. An accountant friend of mine recently asked me to write a blog for his accounting firm's web site. He likes my writing better than his own. A resort where I stayed asked me to write a review. None of these examples wanted to monetize the content, but it's not far. Getting prestige for putting out a blog is usually higher priority for them than the actual analytics, and they probably wouldn't know what to do with those analytics.

The first issue with analytics is why you want it and what you expect to get out of it.

Matt Sullivan

Co-author of Publishing Fundamentals: Unstructured FrameMaker 11. Trainer and Developer in Tech Comm and eLearning

Sorry Neil, I don't know anyone who has done this, but I'd do it on spec for a client if they were interested!

Hagay, I respectfully disagree with your assessment of GA only in terms of monetizing content. While a monetary transaction is certainly *one* goal of GA, knowing more about your users and knowing what they do (and don't) respond to are never a bad idea. Improving customer service and decreasing employee time spent on problem solving affect the bottom line as much as a few more transactions.

And while a small company or resort may not have time to fully contemplate GA on their blog, or even their site, many companies have the scale to do so.

Even small orgs can use GA to determine their spend on marketing, content dev, and other significant activities.

I thought Evan's original premise was a good one, and would bet dollars to doughnuts that embedding the GA code would be do-able, and worthwhile for any org that currently does GA.

Neil Perlin

President, Hyper/Word Services

Hagay,

Thanks for your post. I don't entirely agree with you regarding tech comm's use of GA since while tech comm (probably) isn't going to be monetizing contact, they still want to know who is using it and its successes and failures (which is basically your point about coordinating with customer service). That disagreement aside, I think your response would make a fine blog post that introduces one aspect of analytics. Do you have a blog on which you could put your post? If not, would you mind if I put it on my blog, with full attribution to you of course, as a discussion point for tech comm?

Regards,
Neil

Neil Perlin

President, Hyper/Word Services

Matt,

Thanks for your post in response to Hagay. I think you and I are seeing a different side of GA because we're in the same field, whereas I suspect Hagay is coming at it from a different angle. (Hagay, true?) Watch the April Intercom for an article about analytics for tech comm as part of a bleeding edge theme to the issue.

Regards,
Neil

Hagay Vider

Technical and Marketing Communications Manager at High Security Labs

Thanks to both of you, Neil and Matt.

Yes, I am coming from a different angle. I have worked with Google Analytics in the past. It was of limited use as a tool for my technical publications, but I more often documented its uses and features in the line of business of the companies where I worked.

The reason GA is so new to technical writers is its limited perceived benefit (I emphasize perceived). GA is not new. It is already very strong in other areas that find its ability to generate revenue or save money. This is also where technical communications can benefit, and benefit the companies who employ the technical writers.

We are already aware how the old school format of technical documentation, which uses the printed page paradigm, is gradually shifting to mostly/only electronic publishing and distribution.

Companies that needed technical documents didn't always see it in full context of its operations and line of business, and neither did the technical writers. What was not so obvious was how technical communications can benefit marketing, sales and support. The technical writers know little about who reads their documentation, how much they actually read (if at all), and especially what content they miss that eventually turns into an expensive service call. This is where the savings comes in - a service call that could have been resolved in advance with a visit to the WebHelp. GA can help locate and link the support expenses to specific items of documented information. I have used GA to a limited extent in my technical documentation, but the traffic was not heavy enough to provide any useful insights.

The newer side is generating revenue through technical communications. I know of companies who are considering monetizing their technical documentation, but none who actually tried to sell it, let alone made any money. This is especially common with companies who market a FREE-MIUM product or service. The initial product is basic and free, but advanced features are only available with a paid subscription or by purchasing the "Pro" version. With this model, users of the basic free product get a short Quick Start tutorial, in a web page, PDF download, Video, interactive Flash, or some combination. The heavier side of technical communications is only provided to paying customers, and is part of the full product support package. Again, I have yet to see a company that succeeded selling its user manuals, but then I am not in contact with every new company.

This is a new area, and certainly "Bleeding Edge."

Matt Sullivan

Co-author of Publishing Fundamentals: Unstructured FrameMaker 11. Trainer and Developer in Tech Comm and eLearning

@Neil, feel free to use this as blog fodder!

I think it's an interesting topic, though as I said I've not implemented GA code in a project yet. If as Hagay said, the sample size is just too small, then perhaps in smaller implementations, it's just not worth it. But even for small samples, you'd get a sense of the number of users, and what they're doing.

Marion Deland

at Capensys Ltd.

Coming in on this late...We use Google Analytics to measure our RH projects for clients all the time. We embed the code into the master, and publish as WebHelp We have a different account set up for each client.

It does have limited use - it can't measure exactly who is reading the files, which is fine because it protects the privacy of the user (important in Europe, especially). But it tells the client which city/country the user is in, and whether it is a mobile device. If you dig down, you can see which pages are accessed the most, which is also useful. (While the overall project is addressed as index.htm, the individual pages are bookmarks, and can be found.)

Hope this helps,
Marion

 

Biola.Digital Conference – Observation 1

I gave two presentations about “mobile” at the Biola.Digital (http://events.biola.edu/bioladigital/) conference in La Mirada, CA last week. The conference focused in large part on the use of technology in ministry or, per the web site, “…vision, knowledge, and relationships necessary to be thoughtful stewards of digital technologies for the cause of Christ.”

To a degree, the use of technology in ministry has the same issues as in any other setting – ensuring adequate server capacity, building a social media presence, dealing with an audience with different technology skills and equipment, etc. But, as in so many markets, the use of technology in ministry also has its own peculiar problems. One, noted by Jason Caston (http://www.jasoncaston.com/) in his presentation “How to Get One Million Social Media Fans”, has to do with the use of social media in a personality-driven environment.

For example, let’s say church X has John Doe as its pastor. (This might just as easily be a conference or company with a specific person as its face.) Pastor Doe has written books, appears in videos on YouTube, and so on. Pastor Doe is the face of the church. For whom does the church solicit followers on social media, Pastor Doe or Church X? It’s important because the departure of Pastor Doe might throw the church into turmoil or kill it outright. The answer appears to be to solicit social media followers on multiple tracks – the personality and the organization. It seems self-evident, but many self-evident things aren’t until after the fact.