Let's have an honest conversation about the dashboard and history interfaces

[BeanAnimal]

I know I keep beating this drum, but each and every time I use the dashboard, I become a bit more disgruntled and a lose a bit more love for GHL.

Speed - (web or app) clearly an issue. Waiting 10-30 seconds for the dashboard to load EVERY TIME you open it is insanity. This is an eternity of spinning symbols.

Session/Cache issues - if you leave the IOS app open, then things get out of whack. You bring the app to the front and in most cases sections of the dashboard timeout and the app has to be quit and reloaded.

Fonts and colors - I wear glasses and still can't read much of the text on the screens. The background is white and many of the labels and data are presented in tiny fonts with low contrast colors. This is (honestly) inexcusable. Look at the image below and tell me that is readable! The temperatures on the left axis are certainly not due to contrast and the axis labels and key are tiny. iPad - just more whitespace and the same size fonts and low contrast. Actual image height should be about 5.5". Of course if you blow it up you can read it.

White space - the dashboard is riddled with whitespace, tiny fonts and useless information. The space could be far better used, with more data on the screen and larger fonts with more contrast.

Lighting panel - way too much space used to convey so little actual information.

Charting panel - fonts to small to read and if you have more than 2-3 trend lines, the chart breaks if you click on anything on web or app, mobile or desktop to zoom or toggle/highlight trends. Why ohh why is there no way to add multiple custom charts as needed. This panel is basically useless other than being able to see a general trend.

Switch channels - agian, tons of wasted space and redundant information. Also as a side not, instantaneous current draw, but there is not power history or graph.

Dosing Pumps - this actually is not too bad, but the bar graphs could be thinner and the fonts larger to allow better use of space. Things like "Dosing Pump 5" need not be spelled out and common nomenclature for ratios could be used to save more space

#5 - KHD Reagent 322ml / 1000ml
|********** 36%..................................|

Etc.

GHL - please get on with rebuilding this into a modern and useable interface or complete the API or give us back the self hosted page option ASAP. This dashboard is an albatross hanging around the neck of Profilux.

 

[Vinny@GHLUSA]

Can't say I'm having any of the issues you're having. Then again, most of the times I close any app I use when I'm done with it. Even if I forget to close it (iOS / android) and go back to it, I wait 5 seconds or so to give the app time to re-establish the connection to the device. I certainly don't expect it to be instantaneous and never have a timeout because that wouldn't be an efficient way to manage a connection that is not being actively used.

The slow dashboard loading problem is a local issue; lack of priority for the device on the network, other devices utilizing a large amount of the bandwidth, signal strength, router's method of wireless device handling, etc.. Don't get me wrong and think I'm downplaying your issues as if they don't exist because they do for you. However, I'm speaking from experience of helping a large number of ProfiLux owners and my comments are based on what I have seen through the years. If this was a widespread problem, we'd be hearing about it from more than a select few users on a global scale. From my perspective, it's usually the same users saying the same thing in different places which gives the impression that this is "typical performance" when it's not.

For reference, here's the typical dashboard load times for a ProfiLux on the web interface and app. Even with a heavy amount of tiles (KHD, IOND, Charts, 16 dosing pumps, Switch channels, etc.), it takes no more than 10 seconds to load which is satisfactory for 99% of users. It's even faster if the user has no interest in having this amount of info on one page. The video shows the interface being accessed on Edge browser.

I suggest you try these things:

• Clear the cache on your browser or trying another one altogether
• Set the ProfiLux as a "priority" device on your router settings; some give this option
• Set the ProfiLux with a different static IP
• Check the signal strength of the ProfiLux to the router

As for your other suggestions (layout and white space), we're always open to hearing it when the right communication channel is used to tell us about it. If the message is meant for GHL, then it should go directly to GHL, not R2R (unless you're looking for input from others). This isn't the place to make it and expect the developers to see it. The best way to get your message across to GHL directly is to open a support ticket. There, the devs can see it and add your suggestions to their to-do list.

 

[Pod_01]

Just to add I would say the latest iOS app improved the performance a lot, but the connection speed is really random, as I write this the connection is quick by stated 10sec load time but over the weekend I was looking at the spinning wheels a lot:

Don‘t get me wrong they are fun to watch for 20-40 seconds but not what I like to do with my spare time and especially every time I go back to the Dashboard.

Since I am unable to reproduce the behaviour and it is so random there is no point for me to generate a ticket, because if I do and we talk and it all works you will tell me “it works as designed “.

If this was a widespread problem, we'd be hearing about it from more than a select few users on a global scale. From my perspective, it's usually the same users saying the same thing in different places which gives the impression that this is "typical performance" when it's not.

I like the hardware and how reliable it has been over the years and that’s why I put up with the frustrating iOS app experience.
I suspect there are other iOS users that just put up with the iOS performance besides myself and @BeanAnimal.

Some of the suggestions provided are for Windows based operating system. I am not sure how to clear cashe on the iOS GHL app and there is no other app. Yes I could use browser but come on we are in 2023 not 1995….
My router is 2m away from the ProfiLux (they are in the same room) any closer and they can sit on top of each other.
Same for closing the app after every use! Really you close all your apps on iOS after every use? Facebook, Slack, Messages etc... Let me put it another way, GHL is the only company that I know that recommends that I close the app after every use!!!

Also to echo @BeanAnimal comments the use of colour pallet, font etc… on the iPhone app is a head scratcher. The best way I can describe it is, yes it is functional, but from user experience it really opposite of fun to use…
My rating for the GHL iOS app is 4 out of 10.
The iOS app can be improved substantially and honestly the GHL iOS developers should visit R2R once in a while. Great things can be accomplished if you can get out of the GHL ticket bubble.

Anyway I am off to watch the fun spinning wheel….

 

[BeanAnimal]

Can't say I'm having any of the issues you're having. Then again, most of the times I close any app I use when I'm done with it. Even if I forget to close it (iOS / android) and go back to it, I wait 5 seconds or so to give the app time to re-establish the connection to the device. I certainly don't expect it to be instantaneous and never have a timeout because that wouldn't be an efficient way to manage a connection that is not being actively used.

Hi Vinny - thank you for the lengthy response! I am glad to have opened a dialog.

I don't expect "instantaneous" either, just something reasonable that doesn't feel like it is being served from dialup.

In general UI design:
A page (dashboard or not) should load in 2 seconds or less. When you hit 3-5 seconds, things feel extremely delayed and over 5 seconds is an eternity. Some of the dash panels are quick (illumination, KH director, level) but sensors, charts, switch channels) can take anywhere from 5-20 seconds each.

This latency comes and goes and some days are worse than others.

The slow dashboard loading problem is a local issue; lack of priority for the device on the network, other devices utilizing a large amount of the bandwidth, signal strength, router's method of wireless device handling, etc..

I design and build networks and hosted services for a living
My home is enterprise grade hardware (currently HP Aruba) with a gigabit fiber connection and the Profilux is on a dedicated network.

Don't get me wrong and think I'm downplaying your issues as if they don't exist because they do for you. ...If this was a widespread problem, we'd be hearing about it from more than a select few users on a global scale.

Honestly, I don't think most people bother and just accept it for the inconvenience that it is, especially when they feel like the time and effort to complain will be fruitless.

For reference, here's the typical dashboard load times for a ProfiLux on the web interface and app. Even with a heavy amount of tiles (KHD, IOND, Charts, 16 dosing pumps, Switch channels, etc.), it takes no more than 10 seconds to load which is satisfactory for 99% of users.

I think this may be where the disconnect (no pun) is.

10 seconds on a good day is (honestly) an eternity for a dashboard that is the primary UI for a product, especially a dashboard that is used multiple times a day and often just for quick reference to a few basic parameters.

Additionally , 10 seconds on a good day is 15-30 seconds or more on a bad day and while this does not sound much worse, the feel is exponentially worse.

In any case, I think it would be more apt to say that 99% of your users begrudgingly put up with 10-15 seconds per load, not that they think it is satisfactory

As for your other suggestions (layout and white space), we're always open to hearing it when the right communication channel is used to tell us about it. If the message is meant for GHL, then it should go directly to GHL, not R2R (unless you're looking for input from others). This isn't the place to make it and expect the developers to see it. The best way to get your message across to GHL directly is to open a support ticket. There, the devs can see it and add your suggestions to their to-do list.

Let me expand on this if I may and touch on (3) points.

1 - I truly believe it is time for the dashboard to be redesigned from the ground up by somebody who designs dashboards for a living. This includes not only the visible user elements, but also the architecture stack used to deliver them. There is a lot of room for improvement in both UI and architecture to bring this up to modern standards.

2 - The API must be a top priority. It would allow those of us capable to build our own dashboards and interfaces.

3 - PLEASE PLEASE PLEASE allow us to have the option of self hosting pages on the P4. I can't fathom this being removed with the current dashboard state, the API being unfinished and the Touch being unavailable.

Thank you for the time.

 

[BeanAnimal]

Let me add something here in the context of customer "satisfaction"


Some 25+ years ago several of us built our own dialup internet service provider. We had to purchase inbound lines in bundles of 16 at a monthly cost of ~$30 per line. So every "upgrade" cost us an additional ~500 per month. We charged $15 per month for service. So it took about 33 "new" accounts to pay for those phone lines and break even.

In the dialup days - people shopped on cost partially, but also on "busy signals". When customers could not get through during busy times, they jumped ship for greener pastures, no matter how good the deal was.

My eventual job was to prevent customer loss as well as maintain profitability. It was actually rather complex with lead times and forecasts, etc. but one of the things we quickly learned was just how far we could push an average customer's patience before angering and losing them. There was a scale that ranged from Loving us through Loathing us.

The only metric that ended up mattering was the user to line ratio (and our bandwidth, but that was secondary, we had T1s for data pipes

At 0 - 3 users per line we lost money but people never got busy signals and everyone loved us.

At 4 - 6 users per line we were barely profitable but still very well liked. Busy signals were rare.

At 7 - 8 user per line busy signals increased at peak times and people began to jump ship, but at an acceptable rate. This was the sweet spot. Customers were not elated, but also not angry. They didn't hate us and may not even have liked us, but they put up with us for the price. We were not raking in money but could maintain growth and income.

At 10 users per line, people began to get angry... not hateful, just openly angry. This was the threshold number.

At 11+ users per line people jumped ship faster than we could acquire new customers and at 16 users per line, we were the spawn of the evil one himself... the worst ISP on planet earth. That user:line ratio issue fixes itself simply due to customer loss...

So the balancing act was NOT making people happy, but pushing them right to the edge of angry.... but not quit there. So my calculus was to watch growth and depending on lead time, order a new bundle when we hit the 8-10 user mark, but not too early to drop us to a loss and not to late where growth would hit 15+ users per line before the new lines arrived 6-20 weeks after the order.

I am a realist - GHL pays for hosted resources and it is a recurring substantial cost that nobody on your end is keen to throw more money at. I feel like we are bouncing someplace between the figurative 6 and 10 users per line...

 

[Dave-T]

Honestly, I don't think most people bother and just accept it for the inconvenience that it is, especially when they feel like the time and effort to complain will be fruitless.

This. And we need to get past the idea that the current response time is acceptable. It just isn't. And given the response times in most software, that people these days have grown accustomed to, it's odd that GHL has these issues in first place. Lengthy delays to load data for graphs when it can't be more than a few hundred bytes? Come on! Most people experiencing these delays are able to stream high definition video on the same network. It's not their network that's the problem!

Until GHL admits there is a problem, nothing will be done.

 

[KStatefan]

The slow dashboard loading problem is a local issue; lack of priority for the device on the network, other devices utilizing a large amount of the bandwidth, signal strength, router's method of wireless device handling, etc.. Don't get me wrong and think I'm downplaying your issues as if they don't exist because they do for you. However, I'm speaking from experience of helping a large number of ProfiLux owners and my comments are based on what I have seen through the years. If this was a widespread problem, we'd be hearing about it from more than a select few users on a global scale. From my perspective, it's usually the same users saying the same thing in different places which gives the impression that this is "typical performance" when it's not.

This is a disappointing response from GHL and is a sign that you do not listen to your customer.

 

[Vinny@GHLUSA]

This is a disappointing response from GHL and is a sign that you do not listen to your customer.

Sorry you feel that way as that's not our intention. As it's been said many times, we're open to suggestions when we're contacted through the proper support channels. If we didn't listen or closed ourselves to any feedback, do you think we'd bother to reply at all? Other companies may outright stonewall you. We reply. Apologies that's not good enough.

 

[Vinny@GHLUSA]

Hi Vinny - thank you for the lengthy response! I am glad to have opened a dialog.

I don't expect "instantaneous" either, just something reasonable that doesn't feel like it is being served from dialup.

In general UI design:
A page (dashboard or not) should load in 2 seconds or less. When you hit 3-5 seconds, things feel extremely delayed and over 5 seconds is an eternity. Some of the dash panels are quick (illumination, KH director, level) but sensors, charts, switch channels) can take anywhere from 5-20 seconds each.

This latency comes and goes and some days are worse than others.


I design and build networks and hosted services for a living
My home is enterprise grade hardware (currently HP Aruba) with a gigabit fiber connection and the Profilux is on a dedicated network.


Honestly, I don't think most people bother and just accept it for the inconvenience that it is, especially when they feel like the time and effort to complain will be fruitless.


I think this may be where the disconnect (no pun) is.

10 seconds on a good day is (honestly) an eternity for a dashboard that is the primary UI for a product, especially a dashboard that is used multiple times a day and often just for quick reference to a few basic parameters.

Additionally , 10 seconds on a good day is 15-30 seconds or more on a bad day and while this does not sound much worse, the feel is exponentially worse.

In any case, I think it would be more apt to say that 99% of your users begrudgingly put up with 10-15 seconds per load, not that they think it is satisfactory


Let me expand on this if I may and touch on (3) points.

1 - I truly believe it is time for the dashboard to be redesigned from the ground up by somebody who designs dashboards for a living. This includes not only the visible user elements, but also the architecture stack used to deliver them. There is a lot of room for improvement in both UI and architecture to bring this up to modern standards.

2 - The API must be a top priority. It would allow those of us capable to build our own dashboards and interfaces.

3 - PLEASE PLEASE PLEASE allow us to have the option of self hosting pages on the P4. I can't fathom this being removed with the current dashboard state, the API being unfinished and the Touch being unavailable.

Thank you for the time.

There's always room for improvement for anything and everything. Trust and believe that if you put this in a support ticket, it will not fall on deaf ears. Of course, certain things require more resources and time, but it doesn't mean we won't implement user feedback.

Whether "most" users "put up" with the existing speeds is unknown. I can only give feedback based on experience from helping those who reached out for help. We can't help those who we don't know need it until they contact us.

Interesting you mention having enterprise grade network. I recall helping another individual (whose not on R2R) with a similar load time issue. He also had an enterprise network. After testing it on a standard network, the problem was resolved. It's hard to say exactly why this happens without doing some more troubleshooting on it. Suffice to say, he was happy the speed was back to normal so that was the end of that case. I'm not suggesting you do the same, but it is something worth mentioning. If you want to open up a ticket, we can dig into it some more and see if anything can be done on our end about it. I can connect you with our networking specialist who can go back and forth with you with the networking terminology.

 

[gerard_zzz]

To post another experience: de loading times of the dashboard are allways good on my phone and tablet, I can easily read all and also wear glasses and I like the layout of the dashboard.

It looks like there are people who have difficulties with the connection or with the lay-out. They blame it on the software; if that was the case there would be hundreds of customers complaining. I see a few saying the same over and over again; then it looks like there is a huge problem. Most people who are satisfied with the app, do not reply here. You can allways make up a story that most people accept the annoyance and do not complain, but that is a guess, not supported by any evidence.

The only conclusion I can draw: there are a few customers who experience problems but it is uncertain if these problems are in the software or in the equipment or setup of those users.

So, here you have a honest conversation

 

[BeanAnimal]

To post another experience: de loading times of the dashboard are allways good on my phone and tablet, I can easily read all and also wear glasses and I like the layout of the dashboard.

I used to own an IT consulting firm and had better than perfect vision. I was often asked to increase font size by users who had trouble reading the screen. I would scoff, and think they were crazy "Just get used to this, more fits on the screen." I would say. Now, 20 years later I understand that I was being an butt and they really couldn't comfortably read what is on the screen.

Personal preferences are fine. But there is no arguing about the font size or contrast. It does not meet any standard of UI design, even if YOU can read it and it does not scale with accessibility settings.

It looks like there are people who have difficulties with the connection or with the lay-out. They blame it on the software;

Um yes, the layout would be the software. As far as connection. Vinny was kind enough to post a typical load time screen capture video above. To me, that is unacceptably slow for a modern UI in a modern app. You may feel it is perfect, that is your prerogative.

Most people who are satisfied with the app, do not reply here. You can allways make up a story that most people accept the annoyance and do not complain, but that is a guess, not supported by any evidence.

And you can always make up a story that most people are happy. You can't discredit ones logic using the same logic you are trying to discredit

So, here you have a honest conversation

Are you sure about that?

I ask because your first sentence was all that was needed, the rest is thinly veiled snark and rather unneeded after Vinny's thoughtful comments.

 

[BeanAnimal]

There's always room for improvement for anything and everything. Trust and believe that if you put this in a support ticket, it will not fall on deaf ears. Of course, certain things require more resources and time, but it doesn't mean we won't implement user feedback.

Thank you again for the response. My hope and goal here was to get some traction via conversation and I think we got that started.

Whether "most" users "put up" with the existing speeds is unknown. I can only give feedback based on experience from helping those who reached out for help. We can't help those who we don't know need it until they contact us.

I don't disagree with your assessment of not knowing. I hope that this conversation gives you another possible perspective though.

Interesting you mention having enterprise grade network. I recall helping another individual (whose not on R2R) with a similar load time issue. He also had an enterprise network. After testing it on a standard network, the problem was resolved. It's hard to say exactly why this happens without doing some more troubleshooting on it.

We see it all of the time and yes it is hard to say exactly what happens on a lot of networks unless that is your area of expertise. I fully understand that, as an IoT connected device provider, much of this is well out of your control and that you get blamed for everyone else's crap wifi, ISP or home network.

Even on a "good" network various access points and IoT Wifi chipsets often do not play well together. This brings up another point - The lack of hard wired ethernet or an available add-on is an oversight IMHO but understand the decision to go Wifi. Unfortunately WiFi is likely one of the biggest end user network problems that you have any way that you slice it. I don't envy dealing with supporting end user network devices, Wifi or hardwired, I did it for 2 decades as the owner of an IT consulting firm.

Ohh back to enterprise - On locked down networks with enterprise firewalls that have various intrusion prevention, packet filters and complex rules, things can get wonky. Apple Talk, Sonos, and other absolute crap protocols can also wreak havoc and cause broadcast storms, etc. That is why (at least in my case) there is no enterprise firewall (I no longer have servers or storage here) and Profilux has its own dedicated access point and dedicated DMZ route.

If you want to open up a ticket, we can dig into it some more and see if anything can be done on our end about it. I can connect you with our networking specialist who can go back and forth with you with the networking terminology.

I will do that when time permits.

As I mentioned above, the goal was several fold.

1 - discuss overall speed
2 - discuss UI design
3 - discuss lack of touch screen, API and self-hosted page culminating in a perfect storm of feeling stuck.

Thanks again for your thoughtful responses.

 

[gerard_zzz]

You sure about that?

I ask because your first sentence was all that was needed, the rest is thinly veiled snark and rather unneeded after Vinny's thoughtful comments.

So you want a honest conversation, but you want to tell others what to write and what not to write. But you have the right to go on and on and on. But the dfference ofcourse is that you know what you you are talking about and others do not know a thing.

Did you already open a ticket? Perhaps that is a better way to investigate if your problems can be solved. It is clear you have time enough when I see the amount of text you produce here.

 

[BeanAnimal]

So you want a honest conversation, but you want to tell others what to write and what not to write.

Not at all. You can write whatever you please and be absolutely happy with whatever you please. It is your right. You are happy with the dashboard speed and layout. I am not.

Ironic that you think my opinion is wrong, invalid or uninformed and yours is righteous. My issue here is with your insulting tone, air of arrogance and your projection, not (at all) your opinion.

But you have the right to go on and on and on. But the dfference ofcourse is that you know what you you are talking about and others do not know a thing.

I absolutely never said anybody was wrong. I said that I do not share your opinion regarding the speed or layout of the interface. Again Ironic that you project and portray those disagree as those who know nothing.

It is clear you have time enough when I see the amount of text you produce here.

Honest conversation? Your contributions here are not in the spirit of honest or pleasant conversation. Your opinion is welcome, the petty insults and tone are not.

 

[Dave-T]

Regarding submitting a ticket as a means towards a solution, vs starting a discussion here - there is quite a bit of value in what is produced in a dialog among users, vs submitting a ticket which only leads to a one on one conversation with an individual user. Vinny - if the developers don't view this forum, you could certainly forward them links to threads such as this one. And if they don't wish to participate in the discussion, they could at least view what people are saying. And the experience of submitting a ticket is often less than steller, for example - you recently advised me to submit a ticket regarding a problem I posted here. I submitted my ticket over a month ago, and have yet to receive a response.

 

[gerard_zzz]

Not at all. You can write whatever you please and be absolutely happy with whatever you please. It is your right. You are happy with the dashboard speed and layout. I am not.

Ironic that you think my opinion is wrong, invalid or uninformed and yours is righteous. My issue here is with your insulting tone, air of arrogance and your projection, not (at all) your opinion.


I absolutely never said anybody was wrong. I said that I do not share your opinion regarding the speed or layout of the interface. Again Ironic that you project and portray those disagree as those who know nothing.


Honest conversation? Your contributions here are not in the spirit of honest or pleasant conversation. Your opinion is welcome, the petty insults and tone are not.

I surrender. You know the best!

 

[Gaël]

Regarding submitting a ticket as a means towards a solution, vs starting a discussion here - there is quite a bit of value in what is produced in a dialog among users, vs submitting a ticket which only leads to a one on one conversation with an individual user. Vinny - if the developers don't view this forum, you could certainly forward them links to threads such as this one. And if they don't wish to participate in the discussion, they could at least view what people are saying. And the experience of submitting a ticket is often less than steller, for example - you recently advised me to submit a ticket regarding a problem I posted here. I submitted my ticket over a month ago, and have yet to receive a response.

Hello,

I have personally assigned your ticket to the developer in charge of this part of GHL Connect since you created it.
Recent events have meant that his workload is quite high, sorry.
I've just seen that you've added a comment to the ticket, so the developer has been notified.

Gaël

 

[BeanAnimal]

I surrender. You know the best!

More back-handed comments.

This has absolutely nothing to do with knowing best. It is about the ability to conduct a civil conversation without demeaning others in the process.

You have 18 posts on this site in 5+ years and a large portion of them are unsolicited snark, insults or back handed remarks directed at people who don't share the same view as you.

I started this thread to engage in a cordial conversation with members of this community and the hopes of GHL participating or at least following. You purpose appears to be contrary to that theme.

 

[areefer01]

10 seconds on a good day is (honestly) an eternity for a dashboard that is the primary UI for a product, especially a dashboard that is used multiple times a day and often just for quick reference to a few basic parameters.

Additionally , 10 seconds on a good day is 15-30 seconds or more on a bad day and while this does not sound much worse, the feel is exponentially worse.

Vendor should have SLA's associated with pages and work flows. Someone should have responsibility to scour the logs and see if they are met. Or they implement code or use analytics. Personally speaking I would have messaged you, asked for your WAN ip address, then reviewed the logs to get a better understanding of which side the has the issue. Few follow up messages I'm sure we would have found out the source.

Peeling the layers off an onion...

 

[BeanAnimal]

Vendor should have SLA's associated with pages and work flows. Someone should have responsibility to scour the logs and see if they are met. Or they implement code or use analytics. Personally speaking I would have messaged you, asked for your WAN ip address, then reviewed the logs to get a better understanding of which side the has the issue. Few follow up messages I'm sure we would have found out the source.

Peeling the layers off an onion...

Reality is that vendors in this space and most niche IoT spaces do not have the resources or expertise or budget to offer support at that level, let alone define, build and monitor SLA based metrics and service delivery.

In the end, as I explained in another thread and partially here... GHL opted for a hosted platform and that hosting is a reoccurring cost but their business model does not have RMR built in other than consumables for KHD/ION and sensors lifespans. It is in their best interest to spend as little as possible on hosting, it is just business.

So they have decided based on whatever metric, that the resources allocated and the the resulting dashboard speed is sufficient.

After viewing the post above where Vinny shared a typical load time video, I am not too far off of that on good days. To me (and this is my opinion) the "typical" dashboard load time is insanely too slow. So there really isn't much to troubleshoot in the sense that it is working as expected or designed.

I don't see this drastically changing anytime in the near future, ticket or not, good intention in the part of GHL or not. I simply hold out hope for a complete API to be delivered very soon or the legacy self- hosted page feature to be re-enabled.

I started to develop a workaround based on the emailable tokens, but it is a messy solution to say the least.