I am thinking about adding actions to a transactional email that asks a customer to fill in a review and currently links to a web-app where a complex questionnaire with several questions and text fields is available.
The amount of data that is collected is far more than would be achievable with the in app review action. However the registration guidelines state that the most high-fidelity action available should be used, but it doesn't really allow for granular enough data input for my use-case.
Should I use a Go-to action? Or is there a way to use the in-app review action to collect part of the data and then redirect to a partially filled questionnaire to offer the option to answer the other questions?
I think you should use the Go-To action. These are for more complex interactions, when you need to provide a direct link to the page where the action can be performed. They are rendered in an email as a button in the subject line that redirects the user to the page specified in the action definition.
https://developers.google.com/gmail/markup/reference/go-to-action
Related
I would like to build an Instagram-like social app, where on the user timeline, you also have his own activities displayed. My first thought was to follow his own user feed but from what I read in this blog post: https://getstream.io/blog/best-practices-for-instagram-style-feeds/
We recommend blocking a user's timeline feed from following their own user feed
Can someone explain why it would be a bad practice ? How could I implement my use case if that is the case ?
Thanks !
Looking at this myself. I think the logic they describe is incorrect. The full statement in context make a little more sense in terms of what I think they mean.
We recommend blocking a user's timeline feed from following their own
user feed, and also blocking users from seeing/following another
user's timeline feed.
The first part of the sentence I believe is backwards. What I think it should says is that the "user" feed should be blocked from following the "timeline" feed. The user feed should just contain actions that the user performed, so it shouldn't contain data from the timeline feed. But if you want the user's activities to appear in the timeline feed than it seems to me that you should definetly make the user's timeline feed follow thier user feed, and prevent the user's timeline feed from unfollowing their own user feed.
The second part that says you should block users from following another user's timeline feed. I believe this is correct because the timeline feed is a series of peronalised items for an individual user. It doesn't make sense to follow another user's timeline feed.
This is how I have implemented my logic and it seems to be working so far, but if I come across any issues with it I'll come back here and update this answer.
Hi #all DOCUSIGN users,
Instead of reviewing the document and sign in every pages of the envelop document, i need to make the process simple. We will show the documents as like Terms & Conditions with agree option. Thus required to get the customer signature, only once in a form (basically within the application) and automatically signed off on every template document, in respective places, with that eSignature. Please suggest me the possibility to do with Docusign in a better way.
Thanks.
One option for single-click is to use the DocuSign Click product with clickwraps.
Here is an example of using it for Terms and Conditions just like you asked.
See if this does what you want.
Few questions about PowerForms
What is the real advantage of using PowerForms? In which case(s) it is most useful?
In Docusign Classic View >> PowerForms, there is an option to download Form Data as XML and CSV. Can we download this data using APIs?
For this question, I referred this thread "Can We get a report for the values filled in radio button in DocuSign Envelope".
PowerForms are an easy way of referencing a DocuSign Template through the API without writing any code. They are intended for less technical end-users who want to quickly access a Template through either email delivery or through a direct link (URL) but don't know / want to code it up. Instead they manually initiate such requests through a created PowerForm.
With regards to the form data question- yes, you can programmatically retrieve the form data through the API. You need to keep in mind that DocuSign tabs (aka fields) are always with respect to recipients and not the document itself.
Therefore, you can make the Get Tab Information For Recipient API call (REST version linked).
I am working on a project that would require some authorized users to 'Approve' or 'Reject' a request.
I would like these actions to be performed right from the user's inbox.
Is it possible to add more than one ConfirmAction that will be disabled once one of them is clicked. If yes, kindly provide a sample markup.
Gmail only supports a single action. If you specify more than one action in your markup, only the first will be rendered.
Thanks for describing your use case, though, we plan to add new action types and this is a legit request.
It is a well known problem to every web developer. As far as I tried to find a good solution to this problem - there was none (or at least I could not find it).
Lets assume the following:
The user does not behave, as he was expected to. The actual project I'm working in uses a navigation within the web portal. But if the user uses the browser's back button, the whole thing becomes jeoprady[?] and the result was not always predictable.
We used the struts framework and stored the back-url into forms - at some places, where we needed a back-url - this has been rendered out of this form's back-url. For there was only a singe field for this information and therefore it was not possible of going back multiple steps.
When you change the "struts-flow" - which may result in using a different form - this information will be lost.
If the user dares to put a bookmark somewhere within your webapp - this information may never have been set and again the result will again be either unpredictable or not flexible enough!
My "solution":
I was storing every navigation-relevant page the user visited onto a stack-like storage into the session. This means a navigation-path is collected and stored for later navigations.
At any page within the webapp, where back-navigations are involved I used a self-made tag which renders the stack-content into the url.
And thats it.
When this back-url was clicked, the stack has been filled with the content from the back-url clicked by the user (which holds all information from the stack once the back-link was rendered).
This is quite clear, because a click on a link is a clear state, where the web developer exactly knows, where the user "is" a this very moment - absolutely independant from whatever the user did before (e.g. hitting the browser back button multiple times). Then the navigation stack is built upon this new state.
Resumé:
It becomes clear, that this won't be the best solution. But it allows storing additional information on the stack like page parameters and some other useful stuff (further developments possible).
So, what were your solutions to this problem?
cheers,
mana
The stack solution sounds interesting, but it will probably break if the user chooses to navigate "in parallel" on different tabs or using bookmarks.
I'm afraid I don't really understand why you have to keep all this state for each user: ideally the web should follow the REST principle and be completely stateless. Therefore a single URL should identify a single resource, without having to keep the navigation history of each user.
If your web app relies heavily on AJAX, you could try to implement something like GMail (admittedly, not so easy...), where each change in the interface is reflected in a change in the page URL. Therefore each page is identified by the current URL and the user can navigate concurrently or use the back button as usual.