Cosmetic facelift or functionality too? If so, any input needed from the community?
(I guess I'm bending the vCampus rules without a programmatic reference...can I flash my All-Star badge and get away with it?)
Please... We'd really like an updated non VB6 version of ProcessBook. It's a great program but could be much better.
Rhys @ WiproI guess I'm bending the vCampus rules without a programmatic reference...can I flash my All-Star badge and get away with it?
Don't need to flash your All-Stars badge! Discussions are very welcome.
As the discussion starter, how about some extra context and comments on what you are thinking about? What kind of facelift in terms or esthetics or functionality?
Reason why I brought up the topic is somewhere, and I can't remember where or when I read it, I saw something about "User Experience designer" and "OSIsoft legacy application" mentioned in the same sentence, so I thought it has to be ProcessBook. I will get some of my limited thoughts on this topic down on paper shortly...I'd be quite interested to see Wolfgang P's input on the UX aspects.
Where if not here you could raise that topic and discuss with the community of PI geeks and the PM's what you would like to see? I am curious what features the community sees as a must and what is just a "nice to have". Personally I am really interested in your thoughts about the future of a scripting solution.
AndreasPersonally I am really interested in your thoughts about the future of a scripting solution.
Long time no post,... but this one of course have my full attention.
@ Osisoft, could you maybe provide a system like connect.microsoft.com.
Where really a controlled discussion about feedback, bugs and product enhancement can go.
For me the current system is a not very effective.their is a public product enhancement / bugs list.their is an internal list which is hidden.their are discussions going on through this forum, vcampus, uc,.....their is stuff which is pushed through sales.
Maybe just a more transparent list, very everyone can vote and comment, provide use cases, some rough drawings,......the votes of course can be revenue weighted.. ;-)
For processbook their are some may open bugs and feature requests already in the system,... with only little progress
I always repeat the little textbox for entering equations,... in terms of usability.and with coresight the same issue reappear (no description of the tags,... just the tagenames,...)
about VBA,... VBA is deprecated from microsoft,... whats nextsome object orientation would be good, where you can create your own graphical elements. (not the work arround with active X controls,....)because they or stucked in the "enhancements requests procedures for years,...)
I would really like when osisoft will have the same "Time Management" as google, where you can spend 20 % of your working time on your own projects.Maybe then some ideas,.. wouldn't take decades, but it instead would just take months,...
Support multitouch for display interaction, Microsoft Surface support, ...
Get rid of command bars, move to dynamic menu icons that pop in/out, fade in/out, etc. Leave all the room on the display for viewing, not cluttered with command bars. Any interaction with elements you either hover over them, right click on them, or what ever. It should be simple but natural. I love the dock on a Mac with the icons for applications. Apply similar layout for ProcessBook for feature access...e.g. a display icon: hover over it and get tool tips of what you can do, click and hold button then get the options to select.
Need to have a level of competency assistant that can be set at different levels, again a natural way to interact with ProcessBook. You create a new dataset and straight away the assistant asks how you want to visualise this on the display - Trend, Value, Bar, etc. You create the visualisation of the dataset, then the assistant suggests some other data tags that may be useful, or suggests complimenting with other symbols, ... The assistant should literally point at problem areas on a display, or highlight symbols in focus of whatever configuration you are changing, or create previews of changes that you can cancel/apply.
In fact ditch datasets in favour of Abacus syntax based calculations (calculation editor is inherited from AF), that can be applied to an AF Server in the user's own personal area of 'ProcessBook' AF Database. Then you can re-use calculations, unlike datasets.
You should be able to select a symbol and choose to copy it but maybe change the symbol type, the data source, or whatever...click, click.
Display management. Support more modern ways of scattering, scrolling through collection of displays (fading in/out). Store display management in AF!!!! (Yes, that is four exclamation marks.)
It would be great to change the scripting engine of ProcessBook but there is no way OSIsoft will invest in that...right?
ProcessBook should "learn" what a user does, learn and adjust accordingly.
Visually, the look and feel seems outdated. Shall we have a "design ProcessBook competition" like some schools have a "design a christmas card" competition? Now where did I put my copy of Photoshop...
Agree with Wolfgang's comments above, especially connect.microsoft.com.
Can't think of anything else right now, have to go make dinner for the family...
I agree with Wolfgang regarding a more structured way of handling feature requests. This should probably be built of the existing techsupport site and linked into vCampus; I don't believe that it should be limited to only vCampus members.
Regarding a ProcessBook facelift.
· ProcessBook looks extremely dated; the whole UI is reminiscent of the mid to late 90's. A lot of the new add-ins have a different look and feel to the core product; which leads to a messy UI. This give a bad first impression.
· Complexity: ProcessBook is very powerful which I like. Unfortunately it is not the easiest tool to use. I get the feeling that PB has grown organically; this has resulted in lots of tool bars and add-ins. Most users simply want a quick way to trend some data. Admittedly Coresight will supplant PB for this.
· Stability: The stability of ProcessBook has declined over the past few releases. We've had numerous problems with PB crashing.
· Scripting: Very few users actually write any ProcessBook scripts. The current scripting language is VBA which is defunct (someone should tell the MS Office team). OSI really needs to look at replacing the scripting engine within PB; I would guess that VSTA is probably the best route.
· AF support: AF is really a second class citizen in ProcessBook. AF is a core component of the PI world but it isn't well support in the clients; this has really hampered our adoption of AF.
· Building graphics for webparts: Although this is a very powerful feature of ProcessBook the end results lack polish. Scaling is a really pain; you can spend as long on getting the scaling semi right as building the graphics. This really needs to be improved.
· PI Graphics vs Activeview: This overlapping functionality leads to confusion. There really should be one method. I know OSI is moving away from SVG to Silverlight. This I believe with solve a number of issues. Unfortunately SL isn't support on things like iPads. Therefore, another solution should be investigated.
· Datasets: Data sets are extremely powerful but they do have some nasty limitations:
o Don't work with ERD's
o The formula editor is terribly; I do mean really bad. As a side not the formula editor for AF Formula Data References is equally bad. I tend to build the formula's in notepad and paste them into AF and Processbook.
· Plugins: Again a nice powerful feature of ProcessBook which unfortunately has some nasty limitations:
o A bad plugin can crash ProcessBook
o There is no deployment support for plugins. Deploying plugins to end users is a nightmare.
· Colours and pens:
o The default colours with PB aren't particularly pretty.
o The limitation of 12 pens needs to be lifted.
· Update the UI. Use something like WPF or Silverlight. Eye candy sells.
· A single mechanism that renders PB displays on the web. This will need to support more than just MS windows; think iPad (IOS), Blackberry (yes I know BB is dying in the US but it is still big in other countries), Windows Phone (not big yet but I believe that this will change). The web rendering should support all of PB's features; SQC, Batch, ...
· Native AF support. AF should have first class support.
· Improved plugin support:
o A bad plugin should not kill the core application
o Some mechanism for deploying add-ins. Preferably something that can be configured to collected updates from a central storage area.
· Data set: I like data sets and I think that they should continue. There is an overlap with AF functionality; but most users don't have sufficient rights to alter the AF database, nor would I want them to. Dataset will need a cleanup:
o Support ERD
o Better editor
o Increase the point limit
· Missing display elements:
o A grid would be really nice. Something akin to a spread sheet style grid
o A table.
o It is time to support something other than VBA.
o Scripts should be support on the web rendering
· Touch support. Touch is here to stay.
· Deeper integration with Notifications. We put a couple of large displays in our control rooms for trends. The trends/displays are built by the mets and used by the operators. It would be nice if a notification could trigger a display change; i.e. switch the display when a notification is fired.
· Multiple platform support. With the advent of iPads I'm afraid that we are moving into a heterogeneous world. It would be beneficial if the displays can be support on multiple platforms (I did hear a rumour that OSI will support Coresight on iPads - I'm assuming using mono*).
The lists above are just a few of my thoughts around this subject.
There is the obvious question regarding Coresight. Why would OSI want to support two "thick" (yes I know Coresight is web only but it isn't really a thin client; it is really a thin’ish client) clients? One possible option would be a thick version of Coresight which would allow a user to deploy the displays back into the Coresight.
I've contacted the ProcessBook PM (Laurie Dieffenbach) to chime in and discuss here.
Howdy everyone... and thanks for opening and contributing to this conversation.
As a side note, you need to stop stalking me, Rhys :-)
There are quite a few ideas being introduced here, so I want to try and address them in at least a first pass, then we can all circle back around to whatever I've missed.
Your comments on how PI ProcessBook currently looks:
I know, I know... it's dated and disorganized and exposes some internal inconsistencies in the presentation of features. That is one of the things that motivated my search for someone to review the design and propose some cosmetic changes. I weigh the desire to improve the presentation against the desire to produce new releases within some reasonable time window. If you believe a cosmetic update isn't worth the effort, this would be a good time to say so.
Comments on the default formatting: The "default" formatting that has always existed in PI ProcessBook was originally determined based on some human factors guidelines, but it is reasonably straightforward to define new defaults. I'm just not sure how many customers actually do that. Furthermore, the varied ways in which customers design, create and display this content would make it difficult for OSIsoft to pick "better" defaults (e.g., if you are displaying on an 80' wide video wall, you certainly don't want a white background and bright colors; but if your users mostly display content on web pages, then that might just be the right thing). Perhaps a set of "styles" optimized for different display contexts would make this more straight forward and easier to apply.
On retiring VBA:
We investigated VSTO a number of years ago. There was no "upgrade path" from VBA and we were told we'd need to install it in parallel with VBA to support both. So, we didn't. In another thread some time ago, I asked for the most common uses of VBA scripting and they seemed to fall into two categories: scripts people used to overcome the complexities of layout and formatting for new displays and additional behavior/visualization within displays that wasn't available out of the box. It seems to me that we can remove the need for the former with deep improvements in how displays are created and formatted. It seems to me we can offer the latter using something other than VBA, and which might also translate to something usable in a web context. There are a number of standards to pick from, so we'd have to pick one.
Your comments on display management/publishing:
We have work ongoing to improve two aspects of viewing/interacting with ProcessBook content outside of PI ProcessBook. One aspect is supporting the native symbols that are not currently covered in PI Graphic (within SharePoint) as well as making that rendering functionality available outside of SharePoint (generally, this approach isn't able to support ActiveX controls, so there are some limitations). The other aspect is making it easier to consume ProcessBook content without some manual translation step. This is a current, shorter-term effort (e.g., less than 2 years away). One of the goals here is to make it possible to consume the result of carefully crafted display in more convenient ways (which implies a split in the authoring versus the viewing/interacting features that PI ProcessBook currently has). My assumption is that viewing/interacting with existing content can be usefully separated from editing/changing features, making it easier to deploy content without the richness of a desktop application, thereby easing the burden of deploying the software to many users. This approach also needs to consider useful ways to store the content so that those users can quickly find and use it.
Comments about datasets/calculations: There are two situations that need to be covered here. One is the need to have reusable configuration (we've got some really useful logic to present data in just the way we want and we want to use that everywhere). The other is the need to have a "personal" definition that we're not sure is useful outside my own needs. The work being done to introduce configurable logic that is reuseable and attached to existing data models (within the Asset Framework) should help with the first case. If the second case needs to continue to be supported in a per user/security-restriction-free manner, then we can continue the paradigm of datasets within ProcessBook displays, but there will be some limitations on its reusability across displays, etc. We might try to bridge that gap by making it possible to promote a "private" defintion to something more centrally available (e.g., publishing to AF).
Comments on deep changes (underlying technology, deployment models, fundamental functionality changes and additions): Again, I weigh cost/benefit. As some of you note, PI ProcessBook is a rich and powerful product with lots of features. If, as described above, we break out the viewing/interacting capabilities from the drawing/layout/creation/editing capabilities, then there's a smaller subset of things to address with a revolutionary (as opposed to evolutionary) change. However, even just basic capabilities for display creation is a full plate of capability to implement in something truly new. So, I weigh the shorter-term benefits that I can provide in a shorter timeframe against the need to find a way to staff a much larger effort, so that some parallel, asynchronous processing can happen. (Hopefully, that was a sufficiently geeky analogy :-)
I have a list of what I consider to be the core capabilities required in a display editor. Unfortunately, I'm involved in all day meetings this week, so I'll promise to publish that list when I have a little more time and we can debate whether its sufficient and maybe do some prioritzing and brainstorming around it.
I hope that's a fair stab at an initial response.
Laurie DieffenbachAs a side note, you need to stop stalking me, Rhys :-)
Ha ha, now I remember...one of my stalking tools LinkedIn helped me out with that bit of intel.
Some of these items could be done in the existing PB but in it really does look dated. Thanks to VBA I have been able to implement some of these on my own.
Some sort of grid would be nice. It's very difficult to line things up nicely when trying to display tabular data.
Auto-scaling that not only grows the scale but shrinks it too.
More objects. Our users have been asking for a gauge. It's available in other OSI tools but not PB. I know there are other ways to get a gauge in PB but having a native object would be nice.
Improved data sets. The editor is difficult to use for large calculations. Also it's possible to view data from many PI servers so why not make it possible to have data sets with PI tags from many PI servers?
Faster update times. We're getting into phasor and other high speed data. I know you can change the update interval in the procbook.ini file but I think the graphic engine might need some updating for high speed data. (I haven't really tested this so I could be wrong)
The current layering system is pretty hard to work with. All layers are displayed in design mode so they are hard to design.
Pretty much all the functionality we need exists in PB or can be coded using VBA. It really comes down to the look and feel. Having a nice modern looking PB on our video walls might help you sell more PI. :)
As promised, here are my current thoughts on the capabilities required for a newer version of ProcessBook for creating displays. The list is generalized and not in any particular order.
I am also posting some information on the PM Blog today regarding enhancements, etc., so please go read it.
Let me know your thoughts on this list.
This list looks like a reasonable starting point. The workflow for approving changes could be handled via things like Sharepoint. I'm not sure that this should be integrated into the actual product. Another alternative would be to integrate a version control system; e.g. SVN, GIT, Visual SourceSafe, ... I would recommend handling this in a manner that the users/clients could select their own poison.
Better integration with AF and AF Models would be nice.
Laurie just posted on the PM blog about the enhancements to PI ProcessBook here.
Thanks for weighing in, Michael.
I agree that display "workflow" may not be a problem best solved by OSIsoft, with the many tools and technologies available already, as you point out. I do think it is important, however, to be aware of the burden of display management on customers (most customers I've talked with are managing hundreds or thousands of displays). I don't know that we'd provide a solution, but we could make it possible for customers to "select their own poison" to make this task easier.
Our current discussion on the "big items" for PI ProcessBook 2012+ (that is, after the release that is currently on deck) includes four general efforts:
The UI refresh is also on this list, currently.
I like the idea of integrating the displays with some type of version control system. This would be extremely useful.
I would be interested in how the "Lauching PI Coresight from a display" would work? Due to a low network bandwidths we are installing Coresight on each operation. So how would the display know which Coresight server to hit?
I'll keep this "version control" link in mind, but I don't have a specific solution in mind at this time.
As far as the PI Coresight integration, there is a mechanism for launching a new display with a list of data items (e.g., tags, AF element attributes) that has been prototyped to work with PI ProcessBook. I don't know the details yet, and there is some work to do to make this an integral part of PI ProcessBook, but certainly there will need to be a mechamism for specifying a PI Coresight server address or name. Real work won't start on this feature until the current release is complete (hopefully, real soon now), but I'll present this situation to the developers working on it, for sure. When you say "installing Coresight on each operation", do you mean that you have a server in each physical location or something different?
I wonder if the time has come to develop a new application that will replace PB. It seems that maintaining backward compatibility and expanding features/capabilities are at conflict and this will only become more pronounced in the years to come. At some point something will have to give way. I'm not saying that PB should not be supported, but there will be a time where everyone will need to migrate forward, it is the nature of software and hardware. Anyway, are there any plans for PB 2.0. This would be like Microsoft going from VB 6.0 to .Net.
Thanks for chiming in, Lonnie! You assess the situation correctly, that there needs to be something new. However, as you can see from my general feature list, above, it is a significant effort.
What we've been working on internally is how to get started on that work while continuing to support the existing application in a meaningful way. The first step we are planning is to provide a means to use the existing display files outside of PI ProcessBook. This is a relatively minor step forward and leverages the kind of work we've already done with products like PI WebParts and its PI Graphic implementation. At it's very base, this strategy provides a clear path forward for supporting existing PI ProcessBook content (with some limitations on things like ActiveX controls and VBA scripts) while work on a new authoring environment can get started. At least, that's how we're thinking about it.
We continue to discuss how a new authoring environment will get built and released, but we continue to work on meaningful additions to the current product in the meantime.
Have you seen the Ubuntu HUD, I love it. Please ditch menus and command bars and go this route with PI Enterprise Search a key contributor to the HUD results within OSIsoft client tools.
That is all.
Interestingly, the first reference I found to Ubuntu HUD was on Geek.com. Hmmmm.....
I do believe this would fall under the "major architectural change" category, so we'll just keep this thought in mind for a larger effort....
It looks like HUD is supposed to get rid of menus etc. If you want touch support you can't get rid of them as easily if at all. HUD is an interesting idea but probably only good for very experienced users.
Matt RivettIt looks like HUD is supposed to get rid of menus etc. If you want touch support you can't get rid of them as easily if at all. HUD is an interesting idea but probably only good for very experienced users.
For touch support you would supplement it with voice (touch and hold a trend symbol and say "change pen 1 colour to red"), but I agree that it is probably a more advanced way of interacting with an application.
[DEAD LINK] vcampus.osisoft.com/.../14630.aspx
Laurie DieffenbachInterestingly, the first reference I found to Ubuntu HUD was on Geek.com. Hmmmm..... http://www.geek.com/articles/geek-pick/ubuntu-12-04-scraps-menus-introduces-a-hud-20120124/
Laurie DieffenbachI do believe this would fall under the "major architectural change" category, so we'll just keep this thought in mind for a larger effort....
What I can see is going to happen is the nice, neat search from Coresight (which I assume is a watered down version of what is to come with PI Enterprise Search) is not going to make its way anytime soon to ProcessBook. In ProcessBook you have the PI SDK tag search, AF SDK attribute search, ... it is too many different ways to get at data that is potentially the same piece of data. Coresight has got it right.Probably one of the only negatives I see with OSIsoft developments is there appears to be a lot of work done in isolation and some products get left behind. Look at PI ACE, still based on MDB...bad (okay, abacus probably influences this). PI Notifications, based on 7, yes 7, PI tags...bad (it is based on AF, why not use the same data store as AF). PI ML, still based on MDB...bad. And so on. All in my opinion. Some of this is changing with RDA, but the lag for some products seems to take far too long. The Coresight search interface should be applied to all next releases (minor or major) of client interfaces, in fact I thought we once saw lots of information relating to applying a common search across all products. Getting at the data from all OSIsoft clients should be the same, what makes each client different is how it then uses the data.
Wow, that was a bit of a mini rant, whoops.
I guess what I was trying to say for ProcessBook is it worth papering over the cracks or should you get the builders in and sort the cause of the crack, then decorate? (Apologies for the bad analogy.)
Do you think there will be a rich desktop version of Coresight that will do what we are expecting a ProcessBook makeover will do?
Retrieving data ...