In my previous blog post, I showed you how to run a PI blog and rise to PI Square fame, even if you don't know much about PI. To become an international celebrity, we must take our ignorance to new places. Next stop: OSIsoft UserVoice.
OSIsoft UserVoice is OSIsoft's feedback website and is by far my favourite place to contribute to the PI community. UserVoice is a forum platform where each thread is a suggestion for a product. If a particular suggestion has already been posted, you can vote for it, otherwise you can write it.
It's not every day that you get an invitation to complain, so in this blog post, we'll take full advantage of it. Too much advantage of it.
Besides rising the ranks, your reasons for doing so may include:
- You want PI to be the best that it can be
- You like sticking it to the man
- Go big or go home
- You finally have a way to release your pent-up rage about PI, and so you do
- Bragging rights
- You are aggressive, competitive, addiction-prone, hyperactive, irritable, negative, ballistic, or all of the above (like me)
Whatever your reason, you'll feel good in the end.
I assume that most people approach UserVoice with the mentality of "if I have a suggestion, then I can post or vote for it". If. Can. Those words scream "optional". We NEED to come up with suggestions, we NEED to show our support for them on UserVoice, and we NEED to look for trouble.
Reactively capture frustrations
For any product, you probably encounter issues, flaws, inconveniences, etc. all the time, and most of the time, all you do is feel frustrated. Every frustration, no matter how minor, is a potential suggestion, and so we want to take note of it.
This is my approach: Whenever I encounter a frustration in or think of an idea for PI, I will immediately jot it down in a dedicated text (.txt) document, where each suggestion is represented by a point-form point, and then I will resume my work. When I get some down time or after work (usually the latter), I will revisit this text document and post the full suggestions on UserVoice.
I may decide to not post a suggestion if:
- It was already posted
- The problem does not exist in a successor product
- Its implementation is a tradeoff that would not clearly make PI better overall
Rather than wait for frustrations and thus suggestions to arise in day-to-day use of PI, you can actively try to think of suggestions for PI, perhaps based on frustrations that you haven't recorded yet. To help you along, ask yourself: what would the ideal realistic PI system be? Jot down any discrepancies between this and the actual PI.
I say "the ideal" rather than "your ideal" because we want to think of the best PI system that would benefit everyone. If a suggestion would benefit others but has no effect on you, it is still worth posting.
Similarly, I purposely added the word "realistic" to rule out answers like:
- a literal money printer
- a free program that you just install and then it uses AI to automate the business & always make the best decisions
In my mind, the ideal realistic PI system would have all of these properties:
Anything that can be automated is automated. Any interaction with a human should be as user-friendly as possible.
Minimizes disk space use, memory use, and network traffic
As secure as possible within reason
Does not use anything deprecated. All successors should be good enough for users to not miss the predecessor.
Futureproof and robust against failures
Can be used on as many systems as possible (cross-platform)
Accessible to users that suffer from impairments, disabilities, or other limitations
Has minimal impact on the environment
All of the above should be promoted and encouraged as much as possible
(It is no coincidence that many of these qualities form the topics of my suggestion compilation blog series. They are software's Elements Of Harmony.)
This list is nice and all, but how does this help us write suggestions if we don't know how to PI? Every Achilles has its Achilles heel, and in PI's case, it's…
Websites and web applications
Any program that interacts with PI must connect to the server on which PI lives. If the PI server goes down, the program won't work. Since that is the case, the program might as well live on the server as well as a web application, accessed simply by entering the correct URL in a client's web browser. This setup also means that any installation/upgrade of the program is done once on the server end rather than repeated for each user's computer. For these reasons, OSIsoft is replacing many of their client-side programs with server-side programs. e.g. PI ProcessBook → PI Vision, PI OLEDB Enterprise → PI SQL DAS (RTQP Engine).
Basically, PI uses a lot of web applications. OSIsoft also has a lot of websites. There are best practices that any website or web application should follow, but it is common for many of these to not/never be implemented.
Our strategy: learn the best practices for web-based content, and for each best practice that each website or web application does not follow, we write a suggestion. This creates a combinatorial explosion of suggestions. You're welcome.
Best practices & scanners for websites and web applications
Similar to how we pondered what the ideal realistic PI system would be, the ideal realistic website or web application would have these properties:
- No spelling or grammatical errors
- Redirects HTTP to HTTPS or does not support unencrypted HTTP at all
- All links on pages use HTTPS
- All embedded/inline content is delivered over HTTPS
- Does not support TLS 1.1 or lower
- Does not use weak cipher suites for TLS 1.2
- Supports TLS 1.3 and OCSP stapling
- Uses security headers. In particular: HSTS.
- Uses HTTP/2
- For websites only, the website should be run using low-carbon renewable energy
- For websites only, the domain should be submitted for HSTS preloading
- For websites only, follows search engine optimization (SEO) best practices, which I will not be covering. In particular: if a web page is meant to be accessible through multiple links, redirect all of them to a single canonical link.
Below is a table that explains some of the terms used above. Skip it if you are already familiar with them.
|Minify||Code is reduced to the bare minimum of what it needs to function the same. Comments and whitespace are removed and the names of variables and functions are shortened. This reduces the amount of code that needs to be sent to a web browser, and less code means less time and energy to send it all.|
|HTTPS||Encrypted HTTP. Helps prevent man-in-the-middle attacks.||Security|
|HTTP/2||Less back-and-forth communication between the server and the client to load the web page. Successor of HTTP/1.1.||Speed|
|TLS 1.3||Less back-and-forth communication between the server and the client to initialize an HTTPS connection. More secure than TLS 1.2.|
|Insecure protocols that have been superseded by TLS 1.2 & TLS 1.3.|
|HSTS||Redirecting HTTP to HTTPS on the server is not enough, since the client can still initiate an unencrypted HTTP connection at any time. If a browser connects to a website that uses HSTS, the website will instruct the browser to use only HTTPS (and not HTTP) with that website in the future. It is also faster for the browser to never attempt HTTP than for the server to redirect HTTP to HTTPS.|
|HSTS preloading||New releases of browsers come preloaded with a list of websites that request HSTS, which avoids the need to visit the website first. This avoids the possibility of the client's first-ever connection to the website being made over insecure HTTP. This also saves a small bit of time if this first-ever connection would have been over HTTP.|
|"Low-carbon" and "renewable" are almost synonyms. Solar, wind, hydroelectric, and tidal power are all low-carbon and renewable. Nuclear power is low-carbon but not renewable.|
Remember that these are best practices for any website or web application, and this is precisely why we don't need to know much about a PI web application before we give feedback on it. We just need to know about the aspect on which we are giving feedback, which we can learn using an online scanner or tool:
|Qualys SSL Server Test||Checks TLS versions, cipher suites, OCSP stapling, HSTS, HSTS preloading, and other security aspects|
|Security Headers||Checks for security headers|
|hstspreload.org||Checks readiness for HSTS preloading. Provides feedback on how to prepare a domain for HSTS preloading. Used to submit domains for HSTS preloading.|
|HTTP2.Pro||Checks for HTTP/2 support|
|GiftOfSpeed||Checks for minification. Most of its other checks and recommendations are based on HTTP/1.1, which are not necessarily a good idea when you are using HTTP/2.|
|Ecograder||Checks for environmental friendliness|
These tools can be used only on public-facing websites and not on any of the PI web applications, which are usually set up to be accessible only from within the customer company. To test the support of different features on PI web applications, we can use web browsers.
To test support for the different TLS versions, I used Internet Explorer, since newer browsers dropped support for TLS 1.0 and TLS 1.1 (which is a good thing). Go to Tools → Internet options → Advanced tab. From there, make sure that only one of the "Use TLS 1.x" boxes is checked. Click OK. Refresh your web pages. If Internet Explorer fails to connect to the web page, then the web page does not support that version of TLS. Repeat for all versions of TLS.
For all other checks, whatever browser you normally use should be fine. You should be able to check support for at least HTTP/2 and HSTS fairly easily. The specific steps for checking these depend on your browser.
To check the minification of the HTML code of a PI web application, view the page's source code or "inspect" the page. If there is a lot of indentation and whitespace and the code seems fairly organized, then the code is not minified.
Website/web application checklist
Below is a table that shows the support or lack of support for different features for different OSIsoft websites and PI web applications. The list of OSIsoft websites is not exhaustive. Links on the ✗s will take you to the corresponding existing suggestion. If there is no link, then a corresponding suggestion had not been written at the time that I wrote this blog post, and I use ✗✗ instead of ✗ to make it stand out more. A dash (—) indicates aspects that I have not checked, usually because I do not know how.
Ideally, the entire table below would be filled with ✓. If you know what any of the — should be, please let me know in the comments.
|Website/web application||Has HTTP-to-HTTPS redirect?||Dropped support for TLS 1.0 or TLS 1.1?||Supports TLS 1.2?||Dropped support for weak cipher suites (TLS 1.2)?||Supports TLS 1.3?||Uses HSTS?||Supports HTTP/2?||Minified?|
|PI Connector administration||—||✗||✓||—||✗||✗✗||✓||✗|
|PI Data Collection Manager||—||—||✓||—||✗||✗✗||✗||✗|
|PI Web API||—||✗✗||✓||—||✗✗||✗✗||✗✗||✗✗|
⁽¹⁾ The max-age is only 60 seconds. It should be increased to at least 1 year.
⁽²⁾ Does not accept an insecure HTTP request, which is even more secure than an HTTP-to-HTTPS redirect
⁽³⁾ Does not support HTTPS and does not seem to be in active development
⁽⁴⁾ In my work, I do not use any PI Integrators, and there are no suggestions based on the column names for PI Integrators
HSTS preload checklist
Below is a table that compiles the error messages returned by hstspreload.org. To my knowledge, none of OSIsoft's domains is currently HSTS preloaded. Ideally, the entire table would be blank except for the "HSTS preloaded?" column, which should be all ✓. If I missed any of OSIsoft's domains, please let me know and I will add them to the table.
|Domain + HSTS preload link||HSTS preloaded?||No HSTS header||No includeSubDomains directive||No preload directive||Max-age too low||Insecure redirect||www subdomain does not support HTTPS||Cannot connect using TLS|
*Based on www.picloudservices.com
Using the checklists to maximize the number of suggestions
In order to maximize the number of suggestions that you write for OSIsoft's websites and PI web applications, you can do the following:
- Write suggestions for ✗✗
- Fill in — with either ✓ or ✗✗ and then write a suggestion for ✗✗
- Analyze other aspects of the websites and web applications (e.g. OCSP stapling, OCSP Must-Staple, accessibility, deprecation warnings, correctness of HTML code, WebAssembly)
- Analyze some of OSIsoft's other websites
PI programs that are not web applications
There is no shortcut for thinking of improvements to PI programs that are not web applications. You will simply need to keep the properties of an ideal realistic PI system in mind and be sure to note every frustration that you encounter with the PI system. Most importantly, you will actually need to be familiar with the program on which you are giving feedback.
However, all hope is not lost. There are suggestions for converting PI System Management Tools and PI System Explorer into web applications. If those get implemented and the web applications are configured suboptimally, there will be plenty more suggestions waiting to be written by PI n00bs. Hopefully, these web applications will be configured optimally if/when they are first released.
Doubts & skepticism
At this point, you are probably asking:
- Isn't it OSIsoft's job to think of ways to improve PI? Why should we waste our time doing free work for them AND continue paying a pretty penny for PI?
- Shouldn't we post only the suggestions that we really care about? Why bother with minor suggestions if they'll probably never be implemented?
Here are my answers:
It is OSIsoft's job to think of ways to improve PI. However, as customers, we have a different perspective, and OSIsoft will never know what we want or think unless we tell them. It's not fair, but there really isn't any good alternative. Besides, if you're going to be stuck using PI at your company, you might as well minimize your suffering with it.
In my opinion, we should be posting any suggestions that come to mind that clearly make PI better (i.e. no questionable tradeoffs). Even if you are not passionate about your own suggestion, someone else might be, and they'll vote for it when they see it. But why not let them post the suggestion instead? Because that person might never think of the suggestion on their own, but when they encounter it, it will make total sense and they will wholeheartedly support it.
As customers, we shouldn't make assumptions about which suggestions OSIsoft will or will not implement. A minor suggestion might be implemented before a major suggestion if the former is much quicker to implement. Vote count has an influence on, but is not the same as, a suggestion's priority. I've posted suggestions that I was not super-passionate about and that had a low vote count, but they got implemented anyways. Similarly, there are some suggestions that others have posted that I and others strongly support, but they have not been implemented yet.
You can't get others' feedback on your feedback if you don't post it, so in my opinion, you should post your suggestions and just keep the following guidelines in mind:
- The suggestion should clearly make PI better (i.e. no questionable tradeoffs)
- Avoid requesting multiple actions in a single suggestion
- Do not duplicate an existing suggestion (this dispels any concerns about spamming)
- Compare and contrast the current behaviour and the desired behaviour
- Do not use the vocabulary of a sailor @$&!
- Be sure to choose a category for your suggestion to make it easier to find. If your suggestion falls under the "Security" category and some other category, choose the "Security" category to make it stand out better.
If OSIsoft doesn't like your suggestion, they'll just decline it.
UserVoice allows you to comment on suggestions. We want to maximize our comments as well. You will need to read through some suggestions and think of comments to write. Here are some examples of types of comments that you can write:
- "I agree!" (not recommended; just vote for the suggestion and leave it at that)
- Explain why you disagree with the suggestion
- Explain why the suggestion is important to you
- Post links to related suggestions
- Request that the suggestion be moved to a different product or category or be merged with an existing suggestion
- Request that the suggestion be marked as "Declined" or "Completed"
As I mentioned in a previous blog post, there was a 3-year period where suggestions and their comments were synchronized to PI Square and so you would earn points for your comments, but that period is over.
Exercising your right to vote
UserVoice also allows you to vote on suggestions. There is only "upvoting" and no "downvoting". Ideally, all of and only the suggestions with which you agree would have your vote. You will need to read through the suggestions to decide if it is worth voting on. There are over 3000 suggestions, so here are some tips for finding suggestions that are worth voting on:
- Check out the 1st page of suggestions for each product. By default, they are sorted in descending order of votes.
- Use the categories to guide you
- You can use my suggestion compilations to guide you, especially the critical and security suggestion compilations. This blog post (the one that you are reading now) is actually listed as the "Ideal website/web application" suggestion compilation.
- If you trust my judgement, you can vote for the same things as me
Exercising others' right to vote
They say that if you want to 10X your productivity, you need to influence others. For your favourite suggestions to get OSIsoft's attention better, you will need to get others to vote for them. Consider occasionally giving a few to your coworkers to read over and vote for. You can also create blog posts on PI Square that compile these suggestions or elaborate on why the suggestion is important, as I have done.
Giving feedback in general
Most of what I have talked about in this blog post is not specific to PI or even UserVoice. In the context of PI, this blog post guides you into becoming an "ideas man/woman" and demonstrates that, even when you don't know much, you can still contribute significantly towards positive change.
Even if 95% of the time, your ideas fall on deaf ears, and only 5% of your ideas actually make a difference, it's still worth it to bring up your ideas, since 5% is still better than 0% and there is no negative impact compared to the status quo if an idea is ignored.
Many companies use UserVoice or have some other feedback mechanism. I encourage you to use these resources. Reach out to politicians. Express your concerns about food workers' hygiene. Send that email asking a company to use environmentally friendly packaging. It doesn't hurt to try to make a difference.