Home  |  Projects  |  Articles  |  About Us

To PowerView or not to PowerView: That is the question.

Paul E. Stansberry, III , WinTOTAL Product Manager

Many of you have been anxiously and patiently awaiting the day when you can get your hands on our first release of the next version of WinTOTAL, "codenamed" Armstrong. That day is fast approaching, but before we get there we'd like to get your feedback on a core decision in designing this next version's user interface.  

 

First, a little background. For anyone hearing the word Armstrong for the first time, that's the codename for the next version of WinTOTAL we're currently working on.  We'll come up with the "real" name later.  But, it's a complete rewrite from the ground up.  We're rewriting the underlying forms engine, all the underlying architecture, everything.  And we're doing it all in C# (pronounced C sharp), the latest in desktop programming technology.  All of this will result in a more stable and flexible WinTOTAL. 

 

The first version of Armstrong we're building is a Standard version, which will skip the bells and whistles, skip even using databases, and stick to basic formfilling and report writing needs. 

 

Over the last few months we've been working to finalize and release DaVinci Mobile Pro, our new field data collection application. As many of you may know, DaVinci and Armstrong will share much of the same "under-the-hood" code, specifically things like the forms engine and QuickLists. And the work we've been doing on DaVinci will make its way into Armstrong moving forward.

 

So, at the same time, we've been re-thinking the report writing workflow in WinTOTAL, as well as evaluating how well our current solution (Aurora) stacks up.  As we build Armstrong, we want to ensure we're not just doing things the same way because "that's the way it's always been" but instead that we're doing things in what is the most efficient and simple way possible. While working through that process, we had a crazy thought we just had to explore.

 

Ideas take time to germinate, and what I'm about to ask is a departure from WinTOTAL tradition. So here goes...

 

What would WinTOTAL be like without PowerViews?

 

Don't answer that yet. Keep reading. 

 

No Free Passes
PowerViews are one of the few features that our competitors have never copied off us (I know you're reading this...).  And as you know, PowerViews break out different report assembly and writing activities into separate areas. For example, the Photos PowerView in Aurora allows you to manage photos, photo pages, access your database of previously downloaded photos and optimize them for brightness, quality, etc. PowerViews are a long established and "institutional" part of WinTOTAL.  But with Armstrong there are no free passes.   We think it's important to re-consider why we have PowerViews, how can we improve workflow in WinTOTAL, and do the plusses outweigh the minuses. And let's not forget that they were added to WinTOTAL years ago for good reasons.  These are the things we've been thinking about here internally, and we want to know what YOU think.

 

To PowerView...

Our current build of Armstrong has PowerViews (Forms, Comps, Sketch, Maps, Photos, etc.), just like Aurora, Athena and Olympus.  Aurora has seven PowerViews, and Athena has 12 (bonus points if you can name them all from memory!). This is a design you're already familiar with.  For example, when you click on the Maps PowerView, you're taken to a different part of WinTOTAL where you can work specifically with and manipulate the map pages. Respectively the available tools on the toolbar change to reflect tools for working with maps.  So, you're taken away from your main forms list and report to work on one piece of it separately. This can be very useful, and frankly we don't get asked "get rid of PowerViews."  But we do get told, "WinTOTAL can seem heavy and overwhelming at times."  Do PowerViews contribute to that?  What do you think? Do you like this workflow and breaking out of tools? 

 

Or Not to PowerView...

Now, what if there weren't PowerViews in the traditional sense?  What if the PowerView buttons didn't take you to a separate part of the program, but instead jumped you directly to the form associated with the PowerView button?  Remember, nobody else uses PowerViews but us. 

 

Let's use the same map example above, but this time without a traditional PowerView design.  What would you think of this?  You click the Maps PowerView button at the top.  You're taken directly to the map form in your report.  Once you click on it, giving it "focus", the toolbars change from your regular formfilling/report writing tools, to map-specific tools. And if you don't already have a map page in your report, the Contents utility pops up so you can choose a form to add.  But all the while, you never really left your report forms.  And then when you click on the Form PowerView button again, you'll be returned to your major form and once you click on it your toolbars will change to reflect the tools you'd need again for formfilling/report writing/text editing. Like Microsoft Word, you never leave your document, and the PowerView buttons simply jump you to differenet parts of it.  And all the while, the toolbars change to keep those you need at your fingertips. 

 

So, the question...

Naturally, there are a number of "gotchas" to consider, but at this point we're more interested in determining if our users like PowerViews and want us to stick with that design.  Do you like PowerViews, or no?  Do you want to veer away from them, or no?  We'd get your feedback now, before charging off in either direction only to find out later that we should have asked you up front.  It's all about you.  :)  

 

If you're having difficulty picturing how this would work, don't worry. It's still not 100% clear to us either. To help take it from the abstract into something more concrete, in the upcoming weeks we're going to make available some prototypes and HTML mockups of both of these workflow concepts so that you can see more clearly what we're describing.

 

As I said before, everything has pros and cons, and we're not including anything in this next version just because "it's always been that way" - no free passes.  And since we're doing a ground-up rewrite, now is the time to discuss these kinds of core design elements and make your thoughts known. 

 

I should be very clear.  Our minds are not made up one way or another.  And I hope I have done a good job describing this without showing any bias one way or another.  If you're interested, give this some thought the next time you're driving to an appointment or have a few "down" minutes. And of course, we want to hear from you. Tell us your thoughts by clicking here to e-mail us.

 

Thank You,

 

Paul E. Stansberry, III

WinTOTAL Product Manager

paul@alamode.com