id8 Blog

Simulating Enterprise Systems

A while back, Michael gave a great presentation on using asset libraries in rapidly visualizing all sorts of projects, from the very small to the very large. It was a great presentation, and we’ve spent a lot of time building our own, and our clients’ asset libraries to great success. But as we’ve gained more and more experience with enterprise systems, like Oracle, SAP, Dynamics, and others, it seems that our approach has gotten much more nuanced. It’s great when you have a whole bunch of pre-made assets and can just drag a ton of pre-made master assets on to a template in the iRise workspace and have a highly functional page in minutes—and that does happen some of the time. But honestly, mostly it does not.

Why?—because enterprise system configuration visualizations are, of course, requirements-specific. And for large projects, chances are you likely don’t have the time or budget to configure every text widget on the page, and make sure every table is data-driven and has meaningful data in the datasheets. Nor, for that matter, would you need to in most cases. So sometimes those highly configurable masters are a pain in the neck. They take way more time than you have, and all you really need is, say, one tab out of 5 to work for your requirements, because the rest is standard.

So the reality is that most of the time, enterprise system visualizations are unique to individual implementations, and are necessarily a hybrid of highly configurable assets and screen shots. The value your visualization consultant offers is in knowing what to simulate, when, why, and HOW. So many companies want to make their implementations and augmentations a matter of a B.A. pulling in your already-created assets. But they will save tons of time and money by having a custom approach for large-scale systems visualization.

We find that, quite, often, an SAP or a PeopleSoft visualization project just happens to require the very sections that the asset library creation didn’t yet get to, or that an asset library uses version 6 of something when the project now requires version 7.

The key to successful large-scale systems visualization is threefold. First, create flexible assets for your asset libraries that don’t necessarily require too much work to make usable. Or simply make a robust version and a simple version when possible. Second, when creating assets, don’t neglect the little stuff—take the time to create button and form element styles and rollovers as much as you do the functionality. Those visual components can be the biggest time suck with something like SAP, for example. And finally, learn when to use screen shots and when not to. We’ve created some of our most compelling visualizations in a few hours for programs like People Soft. Companies won’t always use the simulation for usability testing, so keep what you’re doing flexible. And remember that MOST of time, your visualization will be a hybrid of quick and dirty on the one hand, and highly configured on the other.

iRise User Group - SF

A few weeks back I represented id8 at the iRise User Group meeting in San Francisco. I was on a panel of four iRise experts discussing topics from the audience during an afternoon session. One particularly lively discussion was about how visualization works with different development methodologies, specifically Agile.

I pointed out how our approach to visualization has a lot in common with Agile principles, and that visualization provides many of the same benefits as Agile development does, and does so more rapidly and without some of the pitfalls that hinder many Agile projects.

Visualization, like Agile, doesn't put requirements documentation at the front end of a project as a separate phase, but rather allows requirements to evolve organically, in an iterative fashion. The difference between iterative visualization and Agile development is that with visualization, the requirements are developed in tandem with a simulation, and with Agile, requirements are developed in parallel with working code. 

This point led to a side discussion about how visualization almost makes development methodology irrelevant, and that even old-school waterfall can work quite well when it includes an iterative visualization phase.

Circling back to integrating visualization with Agile, I described an approach that we have used successfully with Agile shops, where we run visualization iterations one step ahead of development sprints -- the visualization serving as a blueprint for the next sprint. At the end of each sprint, the working application can be compared against the visualization, and any need to adjust or compromise due to technical limitations can be addressed immediately. In this way, visualization can accelerate and enhance Agile development, while following up each visualization iteration with a development sprint makes sure the vision is grounded in reality and on track.

After the discussion panel, we were all given a sneak peek at iRise 8, due to be released early next year. Unfortunately there's not much that I can say about it without violating my vow of secrecy, except that it will be way cool! But stay tuned... we'll be sharing details and posting reviews as soon as we are able.

How Much To Simulate?

This question seems to come up a lot lately.

A related issue often comes up a lot as well—how do we know if a simulation is “simple” or requires more functionality at the outset of a given project? My initial answer is that we don’t. I can think of many examples where we think a given visualization project is going to be simple, and it ends up requiring multiple datasheets, tons of conditional logic on what appears on the screen, and the combination of high graphical fidelity and high functionality. Conversely, I’ve worked on projects where I think it’s going to be some really involved simulation with Web 2.0 multiple Web 2.0-type elements, and it turns out to be pretty straightforward wireframes with links.

This?

Or this?

At id8, we’ve had lots of conversations about different prototyping tools for different types of projects, and which tools have capabilities for different types of simulation. It seems all very well and good to say, well use an easier tool if it’s simple, and a more robust tool if it’s complex.  But what happens when it suddenly turns more complicated because the client realizes the power of rapid prototyping and wants to use the prototype for early usability testing, or training? Do we then spend the time to migrate to a new tool and try to explain to a client that now they need to buy a different tool, with additional licensing costs, and that we have to rebuild now in this other tool (and cost the project unforeseen expense)?

At first I thought my answer was simple—use the tool that has the greatest capacity in terms of functionality, and that way you’re covered. But then I realized that that was too pat an answer.  I think that just maybe I spent too much time thinking about which software tool was most important, when really I think the answer lies in our ability to facilitate that answer.

Too often, I come in on a project and am asked to simulate this or that wireframe. Visualization is brought in as a step in the process.  And at that point, it’s difficult to know what the simulation is going to be, or how complex it needs to be. Flat wireframes, even when seemingly rich and complete, tend to leave out more than they know. So one spends much time trying to figure out what the gaps are, because we aren’t involved from the beginning.

And overly simple as it sounds, I’m coming to believe that’s the answer—always make your visualization team a part of the process from the beginning. At id8, we’re not “prototypers,” we’re application definition specialists. And as I reflect back, our most successful projects are those where were just that—involved in defining the application as early as possible—when we’re all sitting together saying “We need an application that has the ability to. . . .”  We need to work with our clients to understand throughout the project what’s too much or too little in terms of prototyping—and work with their experience and knowledge in order to visualize just the right amount. If we know more from the beginning, we can make much more educated decisions about which software tool to use most effectively.

So I guess the most important tool is Us.

Put the Rider in the Wind Tunnel

It's nearly summer in Chicago, so I've got bicycling on the brain. I was recently out visiting bike shops, trying to figure out which triathlon bicycle I should buy. I asked the bike shop owner the difference in aerodynamics, comfort and speed between two particular bicycles. He told me that one tested especially well in the wind tunnel testing for aerodynamics, but he also mentioned that he didn't put too much weight in wind tunnel data.

"Why not?" I asked.

He explained that in wind tunnels they don't often use people on the bikes, but dummies meant to mimic a human rider. He said it's difficult to get professional riders to spend the kind of time they need to in a wind tunnel. Of course, I thought, I would totally want to volunteer for such a thing! I'm a rider who wants to know how those data translate to amateur racing. These bike companies do a LOT of prototyping right on the spot, with different molds for pieces of the bike ready to be made to test different structures.

The problem is not using actual riders who aren't either dummies or paid professionals.

We face the same problem in using rapid prototyping for applications. We spend a lot of time in business analysis, making decisions with a business owner or UI expert. And we can create some pretty cool and complete visualizations. But formal usability testing with actual end users is almost universally a "nice to have," rather than a centerpiece of design and production. We end up with a lot of applications that should be great on paper, but often face many change requests from actual users.

I've mentioned in past blog entries that we need to use more specific data--and this posting is a continuation of that theme. But I'm feeling more emphatic than ever about specifically usability testing. Like with the bicycles, our rapid prototyping loses so much of its value when it's not tested sufficiently by its most common "riders."

The more I think about it, the more it seems crazy to ever NOT do it. And those of us who do visualization should be at the forefront of that push. Why use the wind tunnel without the end rider? Why use iRise without the end user on the prototype? Visualization provides an opporunty we didn't have before--to test usability before the application is even built. Let's push hard to take advantage of that.

Marathon UI

We tend to think of user interfaces as proximate machine interfaces where one user at a time (or sometimes more than one) creates inputs that create a given range of outputs, usually through voice or touch.  But arguably, ANYthing with which we interact to produce an expected output could be considered an interface.

As Michael mentioned, I recently ran the Boston Marathon. And I run a lot of races in a given year. So I’ve been struck recently with the ways race registration and races themselves seem to have become more and more informed by principles of usability and user interface design. If we think of UIs as inputs and expected outputs in a given fairly confined system, our definition can be fairly broad.

In most races, you register online from the race website, and then sometime before the race, there is a “packet pickup,” where you receive your bib, timing chip, race t-shirt, etc. Especially in the higher-end races, these races have become highly complex systems with very visual interfaces and unique branding to promote effective human-system interaction, as well as brand equity.

Much like the transition from early websites with text only (what a colleague of mine calls "developer UI syndrome"--apologies to developers) to Web 2.0, races have evolved from posters with handwritten notices that say “A-L Here” to sophisticated three-dimensional user spaces that are now big co-branded businesses.

I'll use the Boston Marathon as an example. It has a great deal in common with a great online user experience—more so than mere signage in a business, or even signs on an interstate. In this case, the user is making specific inputs and getting specific individual outputs form the “system.” It also has over 25,000 registered “users.”

When you register, you go their well-designed website. The brand, and your user identity, are established:

After registration, you get a similarly branded brochure in the mail (AND in email). It’s really similar to a confirmation email:

You use that card to go to the race “expo” to get your packet "output":

And your race bag—the only bag you’re allowed to check at gear checked—also designed around your system identity—as a user you know exactly where to drop off and pick up your belongings—bus windows with your user identities categorized:

Even the finish line in consistent:

After you finish, you’re guided through a series of interfaces to get food, timing chip removal, and finisher medals:

And your results, the final system outputs, are sent in exactly the same fashion:

(yeah, those are my results)

There’s more--signage along the course itself, co-branded clothing and other gear, etc. This kind of consistency and ease, especially in three-dimensional space, is something I can learn from. It also helps me learn more and more about related but separate systems and usability across applications.

I Love Data

A while back I blogged about expanding our definition “user-centered design.” But I want to return to this issue in light of the most recent public debate on usability—the new Facebook UI.

I’m not going to list the “mistakes” they made in this interface or praise its design, either. There are plenty of folks doing just that in blogs all over (see http://www.burningthebacon.com/2009/03/16/new-facebook-interface-fails-usability-test/ about its usability feature changes, and http://www.forrester.com/Research/Document/Excerpt/0,7211,47046,00.html about Forrester research regarding the Facebook UI)—and I’m fairly ambivalent about it, because for the most part, I know it will change soon again anyway. One thing I will praise social networking sites like Facebook for, though, is that even though they recognize that people get USED to interfaces and get annoyed when you change them, that you have to keep changing them.

As annoyed as people initially are, new users are MORE annoyed when you keep an old UI that eventually becomes outdated or obsolete.  Take the example of large-scale enterprise software, like SAP, or PeopleSoft. When initially designed, they were revolutionary, and still are for their sheer power. But they continue to face a problem where old users have taken years to get used to the interface and DON’T want it to change, while new user find if cumbersome and poorly designed by today’s standards. Facebook, for example, keeps its UI iterative on a short timescale, and for that I praise them.

What I really do think is needed in usability studies is simply MORE DATA. One of the most popular blogs for the 2008 U.S. elections is fivethirtyeight.com (check it out—it is a lesson in analysis). It is wildly popular, because these guys KNOW DATA and use it well and in an accurate, predictive, or explanatory way. They’re statisticians, and they know social science. I argue that we need such a quantitative revolution in usability (and UI designers can help them some, too—you’d know that if you’ve used statistical software like SASS, SPSS, or STATA). Let’s regress!

In usability, we do a great job of filming users, asking questions, and applying more universal cognitive principles, but we don’t do such a hot job of using significant or representative samples, or using standard methodologies in survey design.  I’m hoping for even more improvement in the science of how applications are used and by whom.

One interesting example is the use of social network analysis—the mapping of individuals’ social networks—such a methodology could be very useful in understanding how user are interrelated. Here is one researcher’s visualization of his Facebook social networks (see http://www.connectedaction.net/2009/03/02/facebook-social-network-visualizations/):

Every single user will have a different social network, and there will be commonalities across populations or groups. But understanding that not all users maintain the same networks, or even use software in the same way--even for the same purpose, is crucial to developing adaptable, evolving applications that use all the quantitative tools at our disposal.

Simulate Anything...

One of the things I love about rapid prototyping through visualization is that there are few, if any, limits. I remember a scene in Apollo 13, when they know they have to fix a potentially deadly problem, and back on Earth, the scientists get a duplicate of all the available materials on the ship in order to devise a solution with just those materials. I see simulation with iRise the same way—creative solutions with a finite set of widgets.  And when we’re able to do something, it helps expand what others, including iRise, are able to help us accomplish. If we can simulate it—it most definitely can be built.

Soon, id8 will post a video of a handheld scanner system simulated using iRise. I determined that we needed to think outside the monitor as much as possible, even when we have to use the monitor to run a simulation. We can create multiple spaces and push the prototyping methodology way outside to web-based applications. Using the scanner interface as well as a barcode interface to the side, we can easily dynamically generate a system that visualizes BOTH interfaces at the same time.

So, given the success I had with handheld visualization, I decided to undertake an experiment. I went out and took pictures of interfaces—any interface at all—to see if I can somehow simulate it using iRise. Take a look:

The first thing I randomly ran across was my thermostat:

So it basically has a few different functions like “Program,” “Hold,” and “Time,” with a couple for different modes (“Heat, “Cool,” and “Auto”), plus an up and down button. So sure, I could pretty easily simulate this, with the digital display.  And it might actually be an effective method for testing such an interface before being built!

So next, I had to go do something in my car:

 

This one is a whole bunch trickier. I COULD simulate the interface for heat, radio, and air, but it likely wouldn’t get me much.—same with the speedometer, etc. In order for this visualization to be useful, we’d probably need to have pedals, transmission, etc. So while simulation might help a tiny amount, it’s probably NOT the best approach to cars (feel free to prove me wrong!). But I was NOT discouraged! I went to the kitchen to find something to eat, and I saw:

The microwave!

So YES, it immediately became apparent the usability of this interface could most DEFINIETLY be tested and designed with the help of visualization. Is it intuitive to press certain combos? What would we expect the display to say at certain points in a process? Are there too many clicks? So I should get a meeting with Frigidaire. .

So all this is getting me excited about possibilities—I should probably check my blood pressure:

I could fairly easily simulate the use of this automatic blood pressure monitor. Would it get me anything if was designing such an interface? You bet it would! I watched an older relative use a similar device and saw how thoroughly confused she was by how to use this device. Had I simulated this ahead of time, I might have solved some of those issues.

So I guess the point is—do what it takes to make your interface or system work the best—get as much visualized as you can—and it will help create the best tested, bought-into systems out there.

Next time you see an interface, of any kind, say “Can I simulate that?” And I’ll be the answer is that you can.

Reusing iRise assets easier in version 7.2

One of our favorite new features in iRise 7.2 is the "Drop as..." option in the Master properties panel.

 

The default selection is "Reference", which is the way masters have always worked. The new option is "Stamp", which basically achieves the same effect as the "Break Master Reference" command that was introduced in the last release. But by making this an option as a property of a master acknowledges the value of using masters explicity as pre-built patterns, or custom widgets. This is something we've been doing for awhile now, and we'll be talking about in our upcoming webinar.

iRise 7.2 adds animation effects

Buried in the release notes for iRise 7.2 under the heading "More iRise 7.2 Enhancements and Fixes" lies a small treasure: animation. Now, when you use the Change Properties Action to move or resize any object, the change will happen gradually, that is, the movement or change in size will be smoothly animated. The most obvious application for this is to zoom in and out and move around images, but the effect works on sections and tables -- and their contents -- as well, which opens up a lot of exciting possibilities.

Previously, we've achieved this effect by chaining together multiple change properties actions, each of which moved or resized objects a few pixels at a time, with very small delays. Now, these action chains can be replaced by a single action.

We've done just this to our "Lightbox Browser" example, featured in our Simulations section.

   

We've made a simplified version of this available for download as an iDoc in our Downloads section.

The only drawback to this enhancement is that it doesn't take into account the situations where you might want to change the size or position of an object without animation. Google Maps is one that comes to mind. Some of our more advanced tricks depend on moving without animation as well, and now these don't work in 7.2. Needless to say we've requested that iRise include the ability to turn animation off in their next release. But overall, we think it's a very cool enhancement.

The Canon of Documentation?

I had a previous life in literature. That is, I spent a number of years as an English instructor and professor. I was especially excited about the idea that the traditional “canon” of literature—you know, the “great works” of literature—was being challenged and re-written. The idea that historical and cultural forces have shaped what we considered “good” literature was revolutionary to me. I’d always been taught it was some ideal aesthetic state or ideal “truth” that made certain writings rise to the top. So it was OK to see African American, women, and other writers as part of “great” literature. Innovation replaced tradition as a dominant mode of deciding what’s relevant in art.

But what on earth am I getting at, you wonder, on a blog specifically designed to address application definition?

In the world of the Web, we have been innovating for years in terms of content, functionality, usability, cultural specificity and diversity. In the world of application definition, I think we’re a little behind. We have clung to modes and methods of application definition that often don’t contribute to a better, more innovative system. We spend much of our time on documentation that’s never read, just because it’s what we’re used to. Even when visualization with iRise is a huge success, we scramble to backflush the simulation with use case documents, and other requirements--documents that, in many cases, are simply no longer needed—to say nothing of how well written or clearly worded these documents may or may not be.

Too many times at large corporations, I’m asked to create numerous documents that literally NO ONE ever reads—and are never crucial to development. Some of it is, in fact, desperately needed and essential to development, but I argue that most of that can be done simply using rapid prototyping, using iRise. Functional requirements documents, use cases, business requirements documents—MUCH of it can (and should) be eliminated.

The value proposition of rapid prototpying with iRise to my mind is this: streamlining the application definition process in such a way as to provide exactly what is required is less time, with fewer resources, and less extraneous and confusing documentation.

While writing this entry, a colleague told me about a booklet put out by 37 Signals called Getting Real (see http://gettingreal.37signals.com). Though its scope is much larger than just documentation, it has a section in it on “Words” that I swear was written for me. It has such appealing section titles as “There’s Nothing Functional About a Functional Spec” and “Don’t Do Dead Documents.” They argue for the relevance and flexibity of more organic and interactive methodologies. I would argue that rapid prototpying with software such as iRise fits the bill.

Let’s work to revise the requirements documentation canon—think radically and innovatively about application defintion. Don’t just use prototyping in addition the piles of documents no one will ever read. Use it in lieu of many of those documents. Like we’ve done with expanding our ideas about what constitutes great literature, let us also then expand and revise traditional documentation with more innovative modes of discourse that are inclusive, dynamic—and that generate great precisionand adaptibility in, and excitement about, the systems we define and build.