LizardTech.com

Archive for the ‘Tools’ Category

Three things to consider

Friday, November 30th, 2012

In a guest post on Act-On’s Marketing Action Blog, LizardTech’s own Dani Calvert has written up three useful points to consider in making the most of your company’s social media presence. We’ll give you a hint: the points have to do with images, three Rs, and mobile devices.

Read it here and if you’re tweeting or “facebooking”, please don’t hesitate to retweet or repost!

Going Boldly Where No Lizards Have Gone Before

Friday, July 10th, 2009

You may have noticed a new product from the Lizard Labs a couple of months ago: GeoViewer 3.0.  What you may not have noticed, however, is that we’ve started using some new technologies to build this soon-to-be-award-winning app.

Installation
GeoViewer is a web download: you click on the link on our website and the app is downloaded and installed right quick.
GeoViewer 3.0 installation

That’s a nice improvement over the way things used to be.  But the really good bit is that the application is also able to detect when we’ve posted a newer version, perhaps with bug fixes or new features, and automatically update itself.  This dramatically simplifies life for you and us: we don’t have to force-feed you new CDs and you don’t have to wonder if you’ve got the latest version.

Case in point: shortly after posting 3.0.0 on the web, we found a small bug we needed to fix.  Nothing major, really, but annoying enough to justify getting a fix to our customers.  And we’d already had thousands of downloads.  What to do, what to do?  In the old days we’d have tossed out hundreds of 3.0.0 CDs and burned a bunch of new ones.  Now, though, we just post 3.0.1 to the web and within a week all the deployed copies out there will notify their users that a new version is available and would you like to go ahead and download it?  (This feature can be disabled, of course: go to Options, then GeoViewer update preferences.)

This functionality comes to us courtesy of a relatively new Microsoft .NET feature called ClickOnce, one of the new technologies we’re starting to use here.

Look-and-Feel
GeoViewer doesn’t look much like it’s big brother, GeoExpress. 
GeoViewer 3.0 screenshot
GeoViewer 3.0 screenshot

Notice the soothing blue-grey color tones and those gentle gradient fills?  Goodbye, battleship gray!

We’re not building consumer-facing Twitter clients out here, and we’re not certainly professional UI designers, but we do realize that there is something to be said for working towards a visually pleasing app, even in this relatively staid world of GIS apps.  Look for all our products to start looking and feeling better in future releases.

Oh, and it’s not just the look-and-feel that have gotten the reboot.  You can’t really see it, but under the covers we’re using another new Microsoft .NET technology called WPF (Windows Presentation Foundation) to build GeoViewer.  The WPF Framework gives us programmers a much better way of expressing and writing the user interface logic – gone are the days of event loops and MFC and WM_PAINT messages: we now use XML to control the application’s appearance and elegant property bindings to control the behavior.

And C#
Since we’re embracing .NET technologies for our Windows applications, we’ve also had to make the switch from C++ to C#.  It’s a happy new world to be in – expressive syntax, rich API, and a garbage collector you can trust.  Some time ago we tried programming under .NET using Managed C++, but it was pretty painful.

Of course, our underlying SDKs will remain as C++ libraries.  We’ve learned enough P/Invoke to be able to write our GUI front ends in C# and have them interop over to the C++ layer for the hard stuff.

Upcoming
We’re pretty jazzed out here about being able to break out of the old InstallShield-MFC-C++ world and use some new technologies that allow us to churn out better products faster.  Look for more goodness as we post more releases in the coming months.

Help for the Helpers – WritersUA 2009

Thursday, April 23rd, 2009

This is sort of an off-topic post, obliquely related to things geospatial by virtue of the fact that our geospatial products come with help documentation. As LizardTech’s technical communicator, I attended WritersUA 2009 at the Westin Hotel here in Seattle a few weeks ago. The WritersUA Conference is the annual shindig for user assistance professionals (a.k.a. tech writers and our ilk).

Overall I was impressed, and in a lot of ways. There were over 300 attendees from all over the country, nearly 25 exhibitors and sponsors, and dozens of presenters over the course of three days. There was free wifi throughout the entire conference space, a huge Twitter monitor, and best of all, the opening speaker was Scott McCloud, who has written/drawn award-winning books (“Understanding Comics” et al.) and did the famed Google Chrome comic book documentation.

As is probably normal, the sessions were a mix of things that sounded information-packed and edifying and things that sounded irrelevant, although there were surprises. For instance, the closing session on illusion and mental models by a comedian/hack magician turned out to be one of the most inspiring sessions of the whole conference, as was Scott McCloud’s opener, even though you might have thought cartooning doesn’t have much to do with user help. And one session I was looking forward to turned out to be just bullet points that I might have come up with myself. The most useful session in terms of how to do things better was a session on improving knowledge bases for better troubleshooting.

I think I heard the word “cognitive” at least twice a day, which I thought was significant. It tells you how important the mind of the user is to UA professionals.

In my opinion there was a superfluity of sessions dealing directly with the Darwinian Information Typing Architecture (DITA), an XML language for documentation that the government is mandating wherever it can these days, and there was an inescapable prevalence of tool-specific sessions, lamentable only because most were not about the tools I’m using.

Notes on some of the most inspiring (in one case depressing) sessions:

Opening Session
On Monday morning Scott McCloud submitted to a Q&A session in which he described how the Google Chrome comic came about, what it was like doing it, and how the end result was received (wildly successful, borrowed from and parodied all over the Internet).  

Scott McCloud

The big thing for me in Scott’s talk was the idea of isolation through sequence, which is what distinguishes comics from other drawn art. Few of us would want to turn our help into comics, but the idea of directing the user’s attention by using the same tools the cartoonist uses – removing everything from the user’s focus except what they need to know at that moment – is something that all of our user assistance projects would benefit from. He also talked about how the mind remembers static images more readily than moving ones, and about the notion of “two cognitive altitudes” (context and detail) and the importance of the balance between them.

As for the man as a speaker, I was amazed at the prehensile-ness of his mind. You could tell from the way he listened to questioners and then reframed their questions that his mind was completely wide open like those big dishes in the desert listening to noise in outer space, and when he listens you can see his brain reaching for whatever metaphor or symbol or phrase that will best capture the essence of the conversation. He’s really a technical communicator at heart. If you ever get a chance to hear him, take it.

User-Centered Design of Context-Sensitive Help
Matthew Ellison’s talk was a great intro to context sensitive help (CSH), in which tips or other help-ish material are built into the app, and are either visible to the user as they work or easily accessed by an icon or underlined phrase. CSH is becoming important as UA writers begin to acknowledge that no one reads help unless they are forced to at gunpoint (more on this, unfortunately, below). But more than an intro, it really gave solid best practices. One point that stuck with me was, “focus on answering likely questions rather than documenting the application.” Many times, we tech writers are tempted to write from our model rather than the users’, but again, more anon…

Best Practices for Embedded UA
Scott DeLoach talked about the most useful ways to embed assistance in the UI in exactly the amount and timing (and even phrasing) needed by the user. It seems to be a scientific fact that as long as you don’t call something “help” and it’s right in front of them, users will consult it. Lots of good info here, such as the fact that a novice will eagerly click “Quick tip” while an expert will want to see something like “Tell me more…”. One takeaway: sometimes thoroughness is less important than usefulness. Scott asked us to ask, “What are the things the user HAS to know in order to successfully complete the task?”

Lessons Learned from Research on “Help”
The percentage of users who consult online help and printed help, respectively, are “virtually no one” and “actually no one.” Those are the facts. Professor David Novick of University of Texas at El Paso seemed from the start to want to make us cry, and from the beginning he drilled home the dour and research-supported truth that we’re wasting our efforts. There was no good news to balance this glum panorama, either. It was a dizzying ride through a milky-way of dismal data points, at the end of which he said, “and when they DO use the help, research shows that it doesn’t make users more productive.” We all went out of there and shot ourselves.

Better Knowledge-Base Articles for Complex Troubleshooting
To my lights, the best session of the lot. I’m glad I have the slides, because I could barely keep up with this guy. David Farkas is a professor of technical communication at the University of Washington here in Seattle. He moved through his slides very quickly, rightly using them only as touchstones for the actual content of his presentation, and if you took notes you missed the next thing. David offered lots of good info I will be reviewing, like how to title KBs most effectively, how to structure them, and how to “reduce the cognitive load” on the user’s mind as they troubleshoot problems. He regards the KB’s purpose as a troubleshooting mechanism for “bugs, known issues, things that fall between the cracks” rather than a body of help topics per se.

Magic and Mental Models: Using Illusion to Simplify Designs
Jared Spool’s “magic” presentation on Wednesday was a fantastic end to the conference. It seemed at first to consist of amusing but unsuccessful attempts to read people’s minds, but that was all just a way of demonstrating Kano’s model and the role of delight, which, nutshelled, says that if you get the basic functionality right (things people need and expect), you can add another aspect Kano calls delight. This is a little extra something the user is not expecting. One example he used is that when you attach your iPod Nano to sync it up the image changes to an image of not only the model you have but also the same color. Jared said most users won’t even notice this, but those who do will experience delight.

Delighted

Jared also explained the difference between the designer’s model and the user’s model this way: none of the Disney imagineers wants a vistor to the haunted house ride to come out at the end and say “Oh my gosh, the speakers around turn #3 were amazing…I have to have that in my house!” The user is supposed to have a model in his mind that says THIS IS A SCARY PLACE, THERE ARE GHOSTS AND HALLOWS IN THERE. (Jared didn’t say “hallows”, that’s my paraphrase.) The designer’s model is different; it’s about wires, mirrors, speakers and other functional components. The point is, we who make products don’t need to explain our model, we just have to make sure the user’s model works.  

In the end Jared pulled off a bona fide magic trick and we were all delighted.  

What I came away from the conference with was a motivation to reduce the “cognitive load” on our users, give them the assistance they need (and only what they need) when they need it, and finally to delight them.

Our customers deserve all that. After all, they have the world on their shoulders.
 

Calling the SDK from C#

Tuesday, October 14th, 2008

Because we support multiple platforms (Windows, Solaris, Linux, Mac), our Decode SDK is written in C++.  Some years ago, our C++ APIs used to regularly lead to the question, “do you support Java?”.  The answer was always sorry, no, we’re not a Java shop and we don’t have any Java bindings… But we’ve always provided a relatively simple C API which we claimed could be wrapped using JNI, and for the most part that made people happy.

For the past year or so, though, all the Java requests seem to have disappeared, only to be replaced by the question, “do you support .NET?”  This usually means “do you have any C# bindings?”, although we do get the occasional VB.NET request.  Our response has been sorry, no, we’re not a C# shop and we don’t have any .NET bindings… But, again, we’ve told people that “it ought to be fairly easy to call out to our C API using P/Invoke, .NET’s Interop functionality”.

Well, recently some of the engineers here at LizardTech HQ have started programming in C# for reals, and so now we actually have just enough in-house expertise on the question to be able to provide some additional help on this one.  While the current DSDK release doesn’t provide any C# bindings, we have put together a very simple example app that shows how to use Interop to access the C API.

The code is, at heart, remarkably simple.  First, you declare your C functions so they can be accessed from within your C# class, like so:

      [DllImport("lti_dsdk_cdll.dll")] 
      static extern int ltic_openMrSIDImageFile(out 
            IntPtr image, string fileName); 

      [DllImport("lti_dsdk_cdll.dll")] 
      static extern uint ltic_getWidth(IntPtr image);

Then, you close your eyes, tap your ruby slippers together three times, and innocently call the functions just like they were real functions:

      // this is essentially our void* pointer 
      IntPtr image = IntPtr.Zero; 
      string infile = "..."; 

      sts = ltic_openMrSIDImageFile(out image, infile); 
      ... 
      uint width = ltic_getWidth(image); 
      ...

You can download the full example from here.

Yes, we know, it’d be nice to provide interop support for the C++ classes so as to give access to the whole SDK… but quite frankly, we’re not sure the market demand is really there yet.  At the very least, though, we’ll try to include interop support for the C API in the next release of the SDK.

Keep those cards and letters coming.

-mpg

FogBugz – It’s smart and it helps us get things done

Monday, April 28th, 2008

This week LizardTech finally retired our worn-out old bug tracking software for something shiny and new.

Our old system, whose name I politely won’t mention, has done a fair job for several years now, but as our engineering practices have developed and matured the software just wasn’t able to keep pace with our needs. Oh, we did try – I’ve got the SQL scars to prove it – but we reached a point where we finally found something that seemed to do everything we needed without needing me to bolt lots of kludgy scripts on top of it.

You see, while the engineers here are really good at writing code and fixing bugs, us manager types have had an increasingly hard time keeping track of all the features and bugs being worked on, which release they are for, when they will be fixed, and so on. We wanted a tool that would allow us to do simple, lightweight, intuitive schedule estimation, as part of the normal bug tracking system, and we think we’ve found it.

We’ve been fans of Joel “Smart and Gets Things Done” Spolsky for a long time, and to varying degrees we’ve adopted his ideas for task estimation and hiring. And so when he came to Seattle last year on his World Tour a bunch of us Lizards hiked up the hill to see just what this FogBugz thang was all about – and we came away impressed.

You can find a lot online about FogBugz, both on the company’s website (they’re called Fog Creek Software) and on others’ blogs and such, so I won’t go into detail here. Instead, let me just point out three things that sets it high above other systems we’ve seen:

  • The interface is only via the browser, which initially had me worried – until I started actually using it. Intuitive interface controls, sweet filtering options, flexible searching, very responsive feedback – one of us commented that this is one of the only Ajaxy apps he’d used that had actually got it all right.
  • Project estimation is fun again. The “EBS” system they use for estimating ship dates may seem a little over the top when described in print – Monte Carlo methods? for project planning?! – but by golly in actual use It Just Works. Of course, the graphs produced are only as good as the data you’ve entered, but that entry process is clean and easy – and, most critical, it’s developer-friendly enough that the engineers need not stress out about careful time-keeping.
  • Tech support is both responsive and helpful. Emails (and forum questions) are quickly and fully answered, with follow-ups welcome. Real, live, breathing humans on the other end of the line – how cool is that?

There’s a lot of other stuff in there we’re not using – Wiki, discussion groups, customer email, stuff like that – we’ll see, maybe later on. For now, it’s a system that gives us much better visibility and control over features and bugs.

Which makes for happy managers and developers.

How cool is that!