Have a burning need to tell us about an idea you have for a new PMF gadget?

Even better, have a burning need to make a new Gadget yourself and share it with others?

We're open to your ideas and input. And we're open to your development too.
To make this work, we want to be there to guide you through making Gadgets - so you can make a really fantastic Gadget of which you can be proud.

Note that Gadget development:

• Follows the general path of WebFOCUS development - it's based on WebFOCUS code
  
• Is built on the PMF development substrate - which means a lot of work is done for you (a lot of really hard stuff - indicator drawing, aggregation to Dimensional, Objective, Perspective and Scorecard levels, weighting, and tolerances - are all handled by PMF's core logic)
  

We know people want doc. So over the next few weeks and months, we're putting together great developer doc that will step you through Gadget creation. Keep your eyes to this space.

I know of a lot of "gadgets", but they are hardware things I buy off a retail store's 'gadget wall'. Is there a new one I can buy that slices 'n' dices, whips 'n' purees FOCUS? Do I need different one for PMF (whatever that is) or will the FOCUS one work for PMF also?

PMF 4 introduced the idea of a dashboard "gadget" which is a re-usable component that shows metric information in a particular way. It's like a lens for analyzing the things you measure.

For example, there are gadgets that specialize in presenting grids of data sorted across a dimension that the user can select. There are other gadgets that show a trending line graph that compares actuals to targets. There are others than admins can use to count the records that have been loaded into particular measures. There are others that let us create alerts, type in metrics for data we're not capturing in external systems yet, or manage our report schedules.

PMF 4.2 ships with 26 Gadgets, and the PMF team at IB is building more of them, and consultants and customers are starting to build them too.

Gadgets also provide a "support layer" that tracks individual user preferences. For example, my trending graph might show metrics for COGS across a 13 month period; yours might show trended metrics for Sales and Profit across a 3 year period broken out annually. The same gadget serves both of us, and with a few clicks we can select how we prefer to let that lens show us the data. And the lens always "remembers" what each of us wants to see. The management of these preferences and the ability to support our ability to choose them is built into the architecture; programmers at your site don't have to create parameter screens and lots of code to do that.

The user experience of a gadget is summed up as "power" "speed of delivery" and "convenience." It spares end users and those deploying dashboards the effort needed to design every single lens to view data. In the traditional world of reporting, every report is a new thing that has to be hand-built. Complex dashboards involve simultaneously presenting information in grids, graphs, charts, etc. These things can take weeks to build in the traditional method, and if you have 2500 users with 2500 different information needs, you'd never get the job done, no matter how fantastic your coding skills are.

Dimensions are defined in PMF and follow the lines of the typical questions users ask "who is affected by this?" "when did this happen?" "where is this problem located?" etc. They're then used throughout as a way to organize, aggregate, and locate information. It's like WebFOCUS OLAP but in many ways richer.

Thanks, Bob.

This isn't necessarily a new gadget, but rather a couple of ideas on how to improve them...

• Ability for the user to revert to the default settings for a gadget. I'm thinking of my users who like to play and make a bunch of changes to their preferences. It would be nice if they had a "revert to default" or something that would let them move back to the original default settings for that gadget. This might be really helpful in those cases where you make changes to a gadget and the user doesn't see those changes because of their preferences. You could simply tell them to "revert".
  
• The other thought would be to make the gadget size part of the gadget instance -- not necessarily instead of on the gadget class -- but rather in addition to it if that's possible? Since we're brand new on PMF, I don't have any concrete examples, but my thought is it would be nice to be able to reuse the gadget class by simply making it bigger or smaller depepending on the page that it resides on. If I understand the process right now, you'd have to make a duplicate class and change the size. The concept of size definitely seems more instance-related than class-related (IMO).
  
• And I think I heard the rumor that it was already coming, but I'd like to enter my vote for making the page designer have some sort of GUI or at least some visual feedback of some sort.

Neither of these items are showstoppers for us, but just observations and suggestions for how they could be improved.

Interesting suggestions. Thanks for forwarding them to us.

• Ability to revert to default... we'll look into adding this. It makes sense; essentially this would wipe out the current personalized settings for a gadget (which currently means it deletes the user's copy of the instance and thus makes the system default instance come up).
  
• Instance based sizing; we're getting away from the exposing of instances as separate objects. Thus your instances are page-specific; if you drop four copies of a class on a page in Page Designer, you've got 4 managed instances each with their own default settings. Size would most probably be one of the things now managed on the Page.
  
• GUI to design Pages (Dashboards). Yes, that's planned for 2008. First it will be available to the Page Designer, eventually it will be something you can expose to end users so they can modify their own Dashboards.
  

quote:

Originally posted by Bob Jude Ferrante:

• Instance based sizing; we're getting away from the exposing of instances as separate objects. Thus your instances are page-specific; if you drop four copies of a class on a page in Page Designer, you've got 4 managed instances each with their own default settings. Size would most probably be one of the things now managed on the Page.
  

Even better!
Thanks!